Core: [Encryption] New user in group can not access shared files

[quiqueck]

I use a group in my ownCloud (6.0.1) installation to share some files. When I create a new user and add it to that group (on creation) it does not have access to those files using the sync client.

Removing the (group-)share and re-adding it will solve the issue.

Steps to reproduce:

1. Enable Encryption
2. Create a group and share a folder with that group
3. Create a new user and add it to that group upon creating
4. Setup Sync-Client for the new user and try to sync that shared folder

[PVince81]

@schiesbn any idea ?

@quiqueck does the folder appear for "new user" or not at all ? Or is it when clicking on the files inside that folder that you get a warning message ?

[schiessle]

That's not a bug. There is not much we can do about it.

To add a user to a encrypted file the file first has to be decrypted by someone with access to the file and than re-encrypted with the new list of public keys. So this can't be done automatically if a user gets added to a group. The decrypt/encrypt happens in various cases

• you remove the share and add it again
• add a new share to the file
• add a new share to one of the parent folders
• edit the file

If one of these actions happens with a user who has access to the file the file gets re-encrypted with an updated list of user, so that the new user will be added.

I close it, because I don't see a way to make it more convenience. If someone has a good idea to improve it feel free to add a comment

[quiqueck]

Yes, it shows up for the new user. And the Sync-Client tries to download the files. There are two different behaviours:

A) The Files start to download to around 80% of the size. Then the Download stalls and cancels.
B) All files are downloaded, but the size is always 0 Byte.

@schiesbn Sorry, didn't see your message when I wrote this reply. Maybe the Sync-Client could simply skip those files and/or display a proper warning and a suggestion how to fix the issue.

[mpscy]

Im facing the same problems here and have two questions:

1) If I remove the share and add it again: will the others users have to download the whole share again? Or will their sync client not notice it, if I do it "fast enough"?

2) Couldnt there be a routine, that gets started via the cron job or from the admin after adding the new user, to go through every file and add the new user? The webapp could prompt, that it will take for about "XY more hours to complete permission-works"

[schiessle]

1) If I remove the share and add it again: will the others users have to download the whole share again? Or will their sync client not notice it, if I do it "fast enough"?

I wouldn't remove the share. Just share the file additionally to the new user and then remove the share again. This is enough to trigger the recalculation of the users with access to the file and nothing will change for user who already have access to the file.

Couldnt there be a routine, that gets started via the cron job or from the admin after adding the new user, to go through every file and add the new user?

No, because a user can only be added by a user with access to the file. Adding a user means decrypting the file key and encrypting it again with the new set of public keys.

[mpscy]

@schiesbn Thanks for your help!

I shared the folder additionally to the new user with full rights, but the effect is the same: Logging in with the new user, I cant access any files. Just browse through them...

Is there anything else I need to do? There arent any errors or warnings...

[mpscy]

I tried it again and it still does not work :-/
With my admin user, I created a new user and added this new user (still with my admin) to an already existing folder. This folder, was before and still is shared also to a group. Now the folder is shared to the group as before and additionally to the new user! (the user is NOT part of the group).

After logging in with the new user and trying to browse through the files, I still cant open any files :-/
But I see the following line in the nginx access logs:
GET /apps/files_encryption/files/error.php?p=0&errorCode=3 HTTP/1.1

After taking a look into the error.php I found that the error with code 3 is saying that the user has no permissions to decrypt the file. I thought by sharing a folder as the owner to a user, this would trigger the re-ecnryption of the whole folder and every subfolder and file within?

At this point I have no more clue, what to do next. With this unability to share the files, our otherwise really great owncloud is being rendered useless.

Any help, tips or hints are very much appreciated!
Thanks a lot!

[mpscy]

Maybe this hasnt something to do with it, but I found the following errors in the owncloud log:

Error    hook    error while running hook (OCA\Encryption\Hooks::postShared): Cannot mutliKeyEncrypt empty plain content     2014-06-28T13:23:10+00:00
Fatal    webdav  Exception: #6 {main}    2014-06-28T13:18:12+00:00
Fatal    webdav  Exception: #5 /usr/share/owncloud/remote.php(43): require_once('/usr/share/ownc...')    2014-06-28T13:18:12+00:00
Fatal   webdav  Exception: #3 /usr/share/owncloud/3rdparty/Sabre/DAV/Server.php(213): Sabre_DAV_Server->invokeMethod('PUT', 'Shared/Solution...')   2014-06-28T13:23:41+00:00
Fatal   webdav  Exception: #2 /usr/share/owncloud/3rdparty/Sabre/DAV/Server.php(473): call_user_func(Array, 'Shared/Solution...')   2014-06-28T13:23:41+00:00
Fatal   webdav  Exception: #1 [internal function]: Sabre_DAV_Server->httpPut('Shared/Solution...')  2014-06-28T13:23:41+00:00
Fatal   webdav  Sabre_DAV_Exception_PreconditionFailed: An If-Match header was specified, but none of the specified the ETags matched.  2014-06-28T13:23:41+00:00
Error   hook    error while running hook (OCA\Encryption\Hooks::postShared): Cannot mutliKeyEncrypt empty plain content

I found this issue here https://github.com/owncloud/core/issues/7269 but I am running OC 6.0.3, so this shouldnt be it, or?

[mpscy]

I was able to narrow the problem down to the following line in the owncloud log:

If I try to add a new user to an existing folder, instead of generating the shared_keys, the system shows the following error:

{"app":"hook","message":"error while running hook (OCA\\Encryption\\Hooks::postShared): Cannot mutliKeyEncrypt empty plain content","level":3,"time":"2014-07-03T14:50:08+00:00"}

Could anyone help and tell me what this means?

[schiessle]

This error means that the data ownCloud tried to encrypt was empty.

[Halderian]

@schiesbn It would be fine to encrypt all files to a group's key. A user could be added to the group and decrypt all files from this share using the group's key.
The reencryption must take place after changing the groups to share a folder/file with.

[jerclarke]

Halderian is right and @schiesbn this is a really depressing ticket.

You imply that the app is behaving correctly when:

• There is no warning that users you create will have broken access to the groups you put them in.
• There is no way for an admin to even know this without logging in as the user.
• The UI doesn't tell the user OR the admin what to do to fix it, and in many cases shows generic errors.
• The UI (as of v.8.x) actually gives a WRONG AND IMPOSSIBLE command to the user, saying the item needs to be reshared which is not possible. You need to unshare THEN share again, or share directly to the user (which I understand why it works, but isn't the logical way). The message should correspond to a direct action (specifically a "reshare" button on items that either finds a way to grant all users in the group access or shows you a warning about why you as a user aren't able to do so).

It seems you consider a buggy, broken experience for both users and admins as normal. Please at least apologize for how crappy the encryption module is when you respond to tickets like this, it would make you seem more like a human being who has tried the software.

P.S. This ticket is ancient and MAYBE some of this was fixed in v9 but either way this ticket is depressing.

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.