Enhancement: calculate and expose actual file permission set

[butonic]

Instead of hardcoding the permissions set for every file and folder to ListContainer:true, CreateContainer:true and always reporting the hardcoded string WCKDNVR for the WebDAV permissions we now aggregate the actual cs3 resource permissions in the storage drivers and correctly map them to ocs permissions and webdav permissions using a common role struct that encapsulates the mapping logic.

• refactor the create*Share methods to use the same stat
• use a common permissions check to prevent users from sharing with permissions they don't have
• map between share role, cs3 resource permissionset, ocs permissions
  • the mapping needs to be simplified by mapping everything to roles
  • we can bring back legacy ocs permissions by mapping them to all legacy role combinations and finding corresponding mappings in cs3 permission sets.
• refactor error handling
  • use ocdav.HandleErrorStatus in more places left for another PR I already touched too many things.
• fix storages and calculate permissions by reading the grants in the path instead of hardcoding ListContainer:true, CreateContainer:true
  • ocis
  • eos I hardcoded returning all permissions, similar to what the ocs api was doing prior to this PR.
  • local I hardcoded returning all permissions, similar to what the ocs api was doing prior to this PR.
  • s3 I hardcoded returning all permissions, similar to what the ocs api was doing prior to this PR.
  • owncloud I hardcoded returning all permissions, similar to what the ocs api was doing prior to this PR.

should fix

• [QA] Resharing is always allowed even when we do not add that permission [QA] Resharing is always allowed even when we do not add that permission owncloud/ocis#552
• [QA] Re-Sharer can increase permissions [QA] Re-Sharer can increase permissions owncloud/ocis#893
• cannot get ocs:share-permissions via WebDAV https://github.com/owncloud/ocis-reva/issues/47
• [EOS] Cannot access public links https://github.com/owncloud/ocis-reva/issues/315
• [EOS] share not created with default permissions https://github.com/owncloud/ocis-reva/issues/316

related

• upload-only public link does not refer to files-drop page, nor are the permissions enforced Upload-only public link does not refer to files-drop page, nor are the permissions enforced owncloud/ocis#723
• path and other information are not shown if a share does not have "read" permission path and other information are not shown if a share does not have "read" permission owncloud/ocis#762
• various sharing settings cannot be set https://github.com/owncloud/ocis-reva/issues/41
• Some failing tests with Webdav custom properties https://github.com/owncloud/ocis-reva/issues/217
• Different propfind response compared with core https://github.com/owncloud/ocis-reva/issues/236
• Sharing seems to work but does not work https://github.com/owncloud/ocis-reva/issues/243
• Accessing non-existing public link should return 404, not 500 https://github.com/owncloud/ocis-reva/issues/290
• Public link enforce permissions https://github.com/owncloud/ocis-reva/issues/292
• [OCIS-Storage] etags don't change for a share receiver [OCIS-Storage] etags don't change for a share receiver owncloud/product#243
• [OCIS-storage] resharing doesn't works [OCIS] [OCIS-storage] resharing doesn't work owncloud/product#265
• [OCIS] share permissions not enforced [OCIS] share permissions not enforced owncloud/product#270
• [OC Storage] etags are not updated on file operations [OCIS][OC Storage] etags are not updated on file operations owncloud/product#279

@labkode eos, localfs, and the other storages need to return a proper PermissionSet for the logged in user so the ocs api can actually return the right ocs permissions. For the ocis I implemented a ReadUserPermissions() that aggregates the permissions on all segments of the path. ReadUserPermissions() is called in GetMD() and ListContainer(). It should be possible to aggregate the permission set for the other storages in a similar manner. Can eos return the acl or permissions for the current user in the fileinfo or is that another call. ... well it might not be necessary if eos really cannot store acls on files directly (only via fuse richacls).

Another option might be to push setting the permission set to the gateway. it could use the storage registry to fill in the permissions without having to stat every path segment, because it can look at the mount points of shares.

Anyway, this PR currently tries to check if the current user is the owner and returns all permissions if that is the case. This works on eos, ocis, local and owncloud AFAICT. not on s3, yet. For shared folders the ocis driver aggregates the permissions. I did not do thet for the other storages yet, but would start implementing it in the same way, unless you have a better idea how to do it more efficiently. For now I want to make it work. Profiling to make it fast comes later.

[update-docs]

Thanks for opening this pull request! The maintainers of this repository would appreciate it if you would create a changelog item based on your changes.

[phil-davis]

Note: drone CI is not running for some reason today. So we are not getting results to know if the behaviour is improved or not.

[labkode]

@phil-davis https://discourse.drone.io/t/new-builds-not-appearing-on-drone/8479

[lgtm-com]

This pull request introduces 1 alert when merging 761ca60 into e791b55 - view on LGTM.com

new alerts:

• 1 for Useless assignment to local variable

[labkode]

@butonic looks good to me. We'll take care of the EOS implementation. There is a conflict to be resolved, maybe just rebase on top of master.

[butonic]

@labkode looking at public links I see that we need to add permission checks and permission set filters to the publicstorageprovider.go from @refs because in the case of public shares ... the storage providers currently cannot determine the permissions ... because only the publicshare manager persists them.

We could implement a publicshare manager that persists shares in the storage ... which would be trivial for ocis. I asume you could persist additional metadata like expiry etc in eos as well ... the question is where should the code live that limits the cs3 permissions set to what the currently logged in user is allowed to do?

We should let the underlying storage system handle as many permission checks as possible, which is would allow a tight eos integration. On the other hand permissions for public links need to be handled in the cs3 publicstorageprovider, based on the share permissions... For the ocis driver we handle permission checks in the driver because we don't integrate with the underlying posix filesystem on purpose.

@labkode do you see my problem with the sharing responsibilities?

[butonic]

anyway ... this PR can go in as is

[C0rby]

Awesome! 👍

[refs]

bug while testing:

1. log in as admin:admin
2. create a folder and share it with Marie
3. as marie: upload a file to the folder
4. as admin: try to delete the file that Marie uploaded to the shared folder

expected: admin should be able to delete the file as she is the owner of the shared folder
got: admin cannot delete file uploaded to shared folder

[butonic]

• moving a file into a shared folder fails with 400

2021-01-07T14:56:58Z DBG gateway: split: parts[1]:Invoice for MBA39A4.pdf != shareFolder:Shares pkg=rgrpc service=storage traceid=5108148c26c8de8e51abc9ab1f42f74c
2021-01-07T14:56:58Z DBG gateway: split: parts[1]:Invoice for MBA39A4.pdf != shareFolder:Shares pkg=rgrpc service=storage traceid=5108148c26c8de8e51abc9ab1f42f74c
2021-01-07T14:56:58Z DBG unary code=OK end="07/Jan/2021:14:56:58 +0000" from=tcp://127.0.0.1:56288 pkg=rgrpc service=storage start="07/Jan/2021:14:56:58 +0000" time_ns=268600 traceid=5108148c26c8de8e51abc9ab1f42f74c uri=/cs3.gateway.v1beta1.GatewayAPI/Move user-agent=grpc-go/1.26.0
2021-01-07T14:56:58Z DBG bad request dst="/home/Shares/Neuer Ordner/Invoice for MBA39A4.pdf" pkg=rhttp service=storage src="/home/Invoice for MBA39A4.pdf" status={"code":4,"message":"gateway: move:error: bad request: gateway: move called on unknown path: /home/Invoice for MBA39A4.pdf","trace":"5108148c26c8de8e51abc9ab1f42f74c"} traceid=5108148c26c8de8e51abc9ab1f42f74c
2021-01-07T14:56:58Z WRN http end="07/Jan/2021:14:56:58 +0000" host=127.0.0.1 method=MOVE pkg=rhttp proto=HTTP/1.1 service=storage size=0 start="07/Jan/2021:14:56:58 +0000" status=400 time_ns=39223900 traceid=5108148c26c8de8e51abc9ab1f42f74c uri=/remote.php/webdav/Invoice%20for%20MBA39A4.pdf url=/remote.php/webdav/Invoice%20for%20MBA39A4.pdf

[lgtm-com]

This pull request introduces 1 alert when merging 074d616 into 23e52dc - view on LGTM.com

new alerts:

• 1 for Useless assignment to local variable

[butonic]

now at 200+ fixed features:

61 | .../expected-failures-on-EOS-storage.txt           \|   8 ---
62 | .../expected-failures-on-OCIS-storage.txt          \| 176 ---------
63 | .../expected-failures-on-OWNCLOUD-storage.txt      \|  47 +--

[labkode]

@butonic https://lgtm.com/projects/g/cs3org/reva/rev/pr-0625c1d67fb1de4e2463c285552d4ead77d61d9e

[phil-davis]

LGTM, the permissions are much better than before. IMO after merging this, people can work on more of the "ToDo"

[phil-davis]

@butonic https://lgtm.com/projects/g/cs3org/reva/rev/pr-0625c1d67fb1de4e2463c285552d4ead77d61d9e

A later analysis at https://lgtm.com/projects/g/cs3org/reva/rev/pr-6affa6881c70272cacb9a1b528350a524a4c180d no longer complains about that.

[butonic]

@butonic https://lgtm.com/projects/g/cs3org/reva/rev/pr-0625c1d67fb1de4e2463c285552d4ead77d61d9e

fixed in c69f470

[ishank011]

I think we can merge this. I'll add the ACL traversal for eos. Since we don't really have permissions support for localfs, we can just let it be.

[ishank011]

Since we're assigning the permissions to the same variable, we do lose the original value. Why are we making a separate copy then?

[butonic]

PermissionSet is a struct which is passed by reference. There are code paths that will change the PermissionSet for files, because they never have delete or create permission IIRC. When listing a folder this would change the default PermissionSet and folders that are rendered after a file would retain the changed default. 💥

[ishank011]

Yes but this particular function is called only from one place and we're forgetting the original reference (since we're storing the returned struct there) so essentially there's no way to get that back.

[butonic]

ok, you are right ... I tried cleaning the permissions and roles stuff up. I think I was confusing this with the storage drivers ...

[butonic]

all tests green!

[ishank011]

Perfect!

[labkode]

About the EOS ACLs, EOS is different to local/ocis filesystems, EOS does not do ACL traversal, ACLs are examined on the node (not from parents). It is possible in EOS to not have any permissions on /a/b/ but have on /a/b/c.

This change in respect to UNIX is one of the design choices to reach high scalability.