Share api does not detect exceed permission granted error on server 9

[nasli]

Steps to reproduce

1.User A share a folder with user B same server with permissions: read, create and share:21
2.User B share this folder with user C same server,

Expected behaviour

Api on server 9 also returned an exceed permission granted error.

Actual behaviour

Default permissions given 21, and you can not give more with the web UI -->correct
But the api accept more permissions, on server 8 given an error "Setting permissions for "X" failed, because the permissions exceed permissions granted to userB"

Server configuration

{"installed":true,"maintenance":false,"version":"9.0.0.13","versionstring":"9.0.0 beta 2","edition":""} master today 4471f35

[rullzer]

I don't get what the error is?

The webUI does a good job finding out the max share permissions. So it does not try to share with full permissions.

If you try to share via the API with more permissions you do get the same error. But this generally should not happen in the UI

[nasli]

The point is that up to know, we are not able to get the permissions of a file that has shared with me.

The work around to handle permissions on the client it is to give the user the change to enable one by one all the permission and when it is not supported the API returned us an error.

On server 8 the API returned that kind of error but with server 9 we do not know witch permissions we should allow

[rullzer]

If you reshare a file with more permissions than you received it with you will get an error from the server. At least I do here.

[nasli]

At least with the last today master no.

[rullzer]

I can't reproduce this:

Steps I took:

1. user1 creates folder `test'
2. curl -u user1:user http://127.0.0.1:1234/ocs/v2.php/apps/files_sharing/api/v1/shares -X POST -d "path=test&shareType=0&shareWith=user2&permissions=21"
3. curl -u user2:user http://127.0.0.1:1234/ocs/v2.php/apps/files_sharing/api/v1/shares -X POST -d "path=test&shareType=0&shareWith=user3&permissions=31"

This fails for me.

[nasli]

@rullzer we update the share with the remote_id:

curl -u user1:user server/ocs/v2.php/apps/files_sharing/api/v1/shares -X POST -d "path=/ab/&shareType=0&shareWith=user2&permissions=21"

remote_id=27

curl -u user2:user server/ocs/v2.php/apps/files_sharing/api/v1/shares/27 -X PUT -d "permissions=31"

And this returned ok 200

[nasli]

Well I still checking it

[nasli]

@rullzer the problem is with update an existing shared
Since we do not know the maximun permissions of a folder that has been shared with me, first of all we share the file with the less permissions, 1. And after that allow the user to update it, and the update request allows to give more permissions that the ones the file has.
curl -u user1:user server/ocs/v2.php/apps/files_sharing/api/v1/shares -X POST -d "path=/ab/&shareType=0&shareWith=user2&permissions=21"
curl -u user2:user server/ocs/v2.php/apps/files_sharing/api/v1/shares -X POST -d "path=/ab/&shareType=0&shareWith=user3&permissions=1"
curl -u user2:user server/ocs/v2.php/apps/files_sharing/api/v1/shares/27 -X PUT -d "permissions=31"

This is allowed

One question, we are still using api version v1.php we should use v2.php? and if so, from that server version we should use one or the other

[rullzer]

@nasli no v1.php or v2.php of the OCS (not the share api) is just passing on the status codes. Nothing v1 should work as expected.

I'll take a look at you test case. Thanks.

[nasli]

@rullzer, with today master we can not update any permissions of a reshared folder, I open new issue #22717

[rullzer]

Ok I can reproduce this... and I think I know why this is happening...
Good spot :)

[nasli]

Fixed via #22740

[lock]

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.