Open ScharfViktor opened 1 day ago
It looks like two different bugs:
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"}
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:
sharedWithMe
endpoint (https://github.com/owncloud/ocis/blob/master/services/graph/pkg/service/v0/utils.go#L787) assembles the libregraphPermissions based on that.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.
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:
user1
creates folderf2
shares touser2
with edit roleuser1
tries to change share role to viewActual:
user1
sees that role was changed but role was not changed foruser2
-> he can edit PROPFIND response body for shared folder doesn't change permissions- > stillDNVCK
so web doesn't disable buttonswhen
user2
tries to create new or edit existing resources -> 500cc @rhafer