can edit files with view access in Collabora and Onlyoffice

[nirajacharya2]

Describe the bug

when a user shares a file (.ods, .odp, docx, xlsx, pptx) with view permission

Steps to reproduce

1. run ocis with Collabora and Onlyoffice services
2. create a file (.ods, .odp, docx, xlsx, pptx) as admin
3. share it to marie with edit permission
4. open the file and don't close it as marie
5. change the permission to view as admin
6. make some edits and close it as marie
7. close the file as marie
8. open the file again as marie can still edit it with view permission

Expected behavior

marie should not be able to edit the file

Actual behavior

marie can still edit it with view permission

Setup

Please describe how you started the server and provide a list of relevant environment variables or configuration files.

running ocis from web repos docker-compose file

OCIS_IMAGE=owncloud/ocis:5.0.0-beta.2 docker compose up traefik ocis wopiserver ocis-appprovider-onlyoffice onlyoffice ocis-appprovider-collabora collabora

ownCloud Web UI 8.0.0-beta.2
Infinite Scale 5.0.0-beta.2 Community 

Additional context

Add any other context about the problem here.

[ScharfViktor]

can confirm it:

Actual:
admin changed role of the locked file and:

• got a message on the web that everything is fine - web issue
• but in the response <statuscode>996</statuscode><message>grpc update share request failed<message/> - correct
• permission is changed for admin (after refreshing page) - backend issue. should not be changed. Expect- edit permissions
• permission for recipient is not changed (still edit) - correct

Screen.Recording.2023-12-22.at.12.23.00.mov

[ScharfViktor]

same issue: https://github.com/owncloud/enterprise/issues/5931

[micbar]

same issue: https://github.com/orgs/owncloud/projects/338

Copy&Paste error?

[ScharfViktor]

Copy&Paste error?

yes. I changed my comment. thanks

[2403905]

@ScharfViktor FYI
v4.0.5, v5.0.0-rc.1
The public links don't have an issue if the behavior below is expected:

1. user A created file.odt and created a public link with an edit permissions
2. user B opens the link.
3. user A changed permission to view -> no errors in a response, code 100
4. user B can edit a file until closes it.
5. after reopen the file, user B can't edit.

[2403905]

After the share has already updated the update the grant is failed because the file is locked.
https://github.com/cs3org/reva/blob/bde86a38bd77917251a8bc97da5a1bd1dc4c85f2/pkg/storage/utils/decomposedfs/grants.go#L313
We can try to roll back the updateShare before returning an error or try to check locks before the updateShare.

The similar issue #6368

[micbar]

I sketched a possible approach in the linked ticket.

[butonic]

@aduffeck and @2403905 were digging into this. most recent comment with options going forward: #8273 (comment)

@aduffeck is in posix wonderland. @2403905 are you looking into this? If so, assign yourself?

[2403905]

@butonic If I am not mistaken @aduffeck added the fix cs3org/reva#4464 and now we shouldn't see an error when try to change the permission of the locked file.

[2403905]

I retested. The bug is gone with the Don't check locks grants changes.