-
-
Notifications
You must be signed in to change notification settings - Fork 4.4k
[stable30] Fix renaming a received share by a user with stale shares #50228
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[stable30] Fix renaming a received share by a user with stale shares #50228
Conversation
…hare Signed-off-by: provokateurin <[email protected]>
… shares Signed-off-by: Daniel Calviño Sánchez <[email protected]>
/backport to stable29 |
Mmmm, it seems that it would be necessary to also backport 715e714, so this is starting to feel riskier than expected. And it also changes the signature of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately this approach will not work: #50389
As mentioned by @provokateurin the cherry-picked commit had to be reverted in master, so the problem still happens there. Therefore this pull request is now longer valid, so it will be closed, and, once the fix is done, it should be backported also to stable30. |
If a user tries to rename a received share and that user has stale shares (shares where the source file was deleted) an internal server error is triggered.
The problem comes from checking the existing shares to ensure that the share is not moved inside one of them. If the source file of a share made by the user was deleted when the node is tried to be got a
OCP\Files\NotFoundException
is thrown; this is not caught anywhere and causes an internal server error.In master the problem was fixed by c2ca99e. After that change
getSharesBy
filters out shares with a no longer accessible node, sotargetIsNotShared
no longer throws an exception. However, the pull request that the commit belongs to has not been backported to the stable branches (and I assume that it will not be, as it is a new feature), so the issue is still present in the stable versions of Nextcloud.c2ca99e looks like a sane check independently of the rest of #49073, so I have cherry-picked just that commit (and added integration tests for the issue). But I do not really know if that could have any problematic side effect 🤷 so a careful review is encouraged :-)
How to test
curl --user admin:admin --request MKCOL --header "OCS-APIRequest: true" "http://127.0.0.1:8000/remote.php/dav/files/admin/folder-to-be-deleted"
)curl --user admin:admin --request POST --header "OCS-APIRequest: true" "http://127.0.0.1:8000/ocs/v1.php/apps/files_sharing/api/v1/shares?path=folder-to-be-deleted&shareType=0&shareWith=user0"
)curl --user admin:admin --request DELETE --header "OCS-APIRequest: true" "http://127.0.0.1:8000/remote.php/dav/files/admin/folder-to-be-deleted"
)curl --user user0:123456 --request MKCOL --header "OCS-APIRequest: true" "http://127.0.0.1:8000/remote.php/dav/files/user0/folder-to-be-renamed"
)curl --user user0:123456 --request POST --header "OCS-APIRequest: true" "http://127.0.0.1:8000/ocs/v1.php/apps/files_sharing/api/v1/shares?path=folder-to-be-renamed&shareType=0&shareWith=admin"
)curl --user admin:admin --request MOVE --header "OCS-APIRequest: true" --header "Destination: http://127.0.0.1:8000/remote.php/dav/files/admin/new-folder-name" "http://127.0.0.1:8000/remote.php/dav/files/admin/folder-to-be-renamed"
)Result with this pull request
The received share is renamed
Result without this pull request
Internal server error