owncloud / ocis

:atom_symbol: ownCloud Infinite Scale Stack
https://doc.owncloud.com/ocis/next/
Apache License 2.0
1.4k stars 183 forks source link

ocm. user cannot change share role #10546

Open ScharfViktor opened 1 day ago

ScharfViktor commented 1 day ago

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:

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 commented 1 day ago

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/v2@v2.26.4/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/v2@v2.26.4/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 commented 10 hours ago

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:

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.