Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Different DAV permissions for space members on the same resource #3373

Closed
JammingBen opened this issue Mar 23, 2022 · 4 comments
Closed

Different DAV permissions for space members on the same resource #3373

JammingBen opened this issue Mar 23, 2022 · 4 comments

Comments

@JammingBen
Copy link
Contributor

First off, I'm not 100% sure if this is a bug. But what I'm experiencing:

  • Create a new space as user admin
  • Add einstein as manager for this space
  • As admin, create a folder folderInsideSpace inside the space

IMO the DAV permissions in the PROPFIND request for folderInsideSpace should look the same for both admin and einstein. But I'm seeing differences:

For the user admin, I get the permissions RDNVCK. For the user einstein, I get SRDNVCK. So the latter includes S, which Web uses as indicator if a resource is shared - which is not the case here.

@C0rby
Copy link
Contributor

C0rby commented Mar 31, 2022

The issue is this line here: https://github.com/cs3org/reva/blob/7ea3143d9a2a7b56826465ac2971e279e6f2667c/internal/http/services/owncloud/ocdav/propfind/propfind.go#L711

We assume that not being the owner on a resource means that it was shared with us. Now with the project spaces this is not true and we can't test the share status like that. Actually I think we should generally rethink the "owner" attribute since technically everything in the back-end is contained in different spaces. If we would get rid of the "owner" attribute we could handle all spaces the same, including personal spaces.

@C0rby
Copy link
Contributor

C0rby commented Mar 31, 2022

I had the idea that when doing a Stat (GetMD on the storage driver level) or a ListContainer (ListFolder on the storage driver level) we could check the grants of the node to see if it is shared or not. But this is not efficient and also incorrect. If the file that is being checked was shared indirectly i.e. the parent folder was shared, then the file wouldn't have the grant. So we would also need to climb up the tree which makes it even more inefficient.

@butonic
Copy link
Member

butonic commented Apr 1, 2022

when accessing /dav/spaces/{spaceid} the ocdav handler first looks up the space. we can use the space type to determine if the S is part of the permissions:

  • if space type is grant we add the S
  • if not we never add S because the currently logged in user is accessing via a real space root

we may need to remember the space id and pass it all the way down to mdToPropResponse()

@micbar
Copy link
Contributor

micbar commented Apr 7, 2022

fixed

@micbar micbar closed this as completed Apr 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants