ocm. user cannot change share role

[ScharfViktor]

Version 7.0.0-rc.1+22d80256d6
Web client version 11.0.2

setup: https://owncloud.dev/ocis/development/testing/#running-test-suite-with-federated-sharing-ocm

Steps:

• 2 users create connection
• user1 creates folder f2 shares to user2 with edit role
• user1 tries to change share role to view

Actual: user1 sees that role was changed but role was not changed for user2 -> he can edit
PROPFIND response body for shared folder doesn't change permissions- > still DNVCK so web doesn't disable buttons

when user2 tries to create new or edit existing resources -> 500

cc @rhafer

[2403905]

It looks like two different bugs:

1. The role update is not working properly - Can't reproduce et.
2. Wrong 403 error handling in the ocm.

2024-11-12 17:29:55 {"level":"error","service":"ocdav","name":"com.owncloud.web.ocdav","traceid":"dd50a4a92d84b76218f3328bfd49fdb8","request-id":"ef6a2ca2-eadf-445a-b75a-89d4907fd2ac","spaceid":"89f37a33-858b-45fa-8890-a1f2b27d90e1$22d16124-959a-45e5-9a1c-65164044f6d2!Lw==","path":"/New file.txt","status":{"code":15,"message":"touch file:Write /New file.txt: 403","trace":"dd50a4a92d84b76218f3328bfd49fdb8"},"time":"2024-11-12T16:29:55Z","line":"github.com/cs3org/reva/[email protected]/internal/http/services/owncloud/ocdav/put.go:241","message":"error touching file"}
2024-11-12 17:29:55 {"level":"error","service":"ocdav","name":"com.owncloud.web.ocdav","traceid":"dd50a4a92d84b76218f3328bfd49fdb8","request-id":"ef6a2ca2-eadf-445a-b75a-89d4907fd2ac","spaceid":"89f37a33-858b-45fa-8890-a1f2b27d90e1$22d16124-959a-45e5-9a1c-65164044f6d2!Lw==","path":"/New file.txt","status":{"code":15,"message":"touch file:Write /New file.txt: 403","trace":"dd50a4a92d84b76218f3328bfd49fdb8"},"code":500,"time":"2024-11-12T16:29:55Z","line":"github.com/cs3org/reva/[email protected]/internal/http/services/owncloud/ocdav/errors/error.go:178","message":"Internal Server Error"}
2024-11-12 17:29:55 {"level":"info","service":"proxy","proto":"HTTP/1.1","request-id":"ef6a2ca2-eadf-445a-b75a-89d4907fd2ac","traceid":"dd50a4a92d84b76218f3328bfd49fdb8","remote-addr":"172.18.0.1","method":"PUT","status":500,"path":"/remote.php/dav/spaces/89f37a33-858b-45fa-8890-a1f2b27d90e1$22d16124-959a-45e5-9a1c-65164044f6d2!Lw==/New file.txt","duration":82.172894,"bytes":0,"time":"2024-11-12T16:29:55Z","line":"github.com/owncloud/ocis/v2/services/proxy/pkg/middleware/accesslog.go:34","message":"access-log"}

[rhafer]

We (@2403905 and me) had a little debug session on this. Here's the findings:

When changing the sharing role of a federated share, the ocmshareprovider only updates its local storage, but does not update the receivedshare on the remote instance. When creating shares the received share was created via POST /ocm/shares/ on the remote side, but the ocm service does not have support for updating shares (there is not PATCH /ocm/shares implementation).

That means the remote side never really gets to see those new permissions. There a multiple things on the receiving end, that rely on the info about received shareds being correct:

• the sharedWithMe endpoint (https://github.com/owncloud/ocis/blob/master/services/graph/pkg/service/v0/utils.go#L787) assembles the libregraphPermissions based on that.
• the ocm storageprovider (https://github.com/cs3org/reva/blob/edge/pkg/ocm/storage/received/ocm.go#L293) does that as well

In the end this does not really lead to elevated permission (or other security problems) as the real permssion check actually happens when trying to download or upload a file. It's just the client (web) that gets confused about what permissions it actually has on a specific resource.

[jnweiger]

reproduced with 7.0.0-rc.3 and web 11.0.4

[rhafer]

@JammingBen This is the one we just mentioned

[JammingBen]

As discussed: The solution is to prevent editing of OCM shares - they can only be created and deleted.

[saw-jan]

updating from sharer side was fixed in owncloud/ocis#9980

[rhafer]

updating from sharer side was fixed in owncloud/ocis#9980

Yes the update on the sharer side works, but that is barely half of what is needed. The share update is not forwarded to the sharee's side, because the http protocol currently lacks an UpdateShare call. (AFAICS it's not part of the spec).