user0 creates folders /test and /test/sub
user0 creates file /test/sub/file.txt
user0 shares folder /test with user1 with read+share permissions (17)
user1 receives the folder /test and can read-download /test/sub/file.txt - good
user1 creates a link share of /test/sub - it has permissions 1 (read-only) - good
user1 uses the sharing API to escalate the permissions of the link share, e.g.
curl --user user1:user1 "http://172.17.0.1:8081/ocs/v1.php/apps/files_sharing/api/v1/shares/3" -H "OCS-APIRequest: true" -X PUT --data 'permissions=15'
Now browse to the link, e.g. my link was http://172.17.0.1:8081/index.php/s/t9dfm6K57yo6a9r
From the link, anyone (in this case user1, who has knowledge of the link) can create/change/delete files.
e.g. delete file.txt and then upload other files, or some different file.txt
Now login as user0.
user0 sees that the content of /test/sub has been changed. But they only gave read and share permissions to user1. They never gave any create-change-delete permissions to anyone.
A user who has shared some folder(s) read-only can have the content of sub-folders modified by a user who has received the read-only share.
Here is a realistic use case where this public link share permissions bump will be a real issue:
Policy/Finance
Policy/HR
etc folders)bob
’s password/authentication details are compromised, or bob
is malicious himselfbob
makes a read-only public link share of each sub-folderbob
increases the permissions of the public link share to read-write-deletebob
browses to the public link share, deletes all the real policy documents and uploads different ones…Now everybody else in the organisation sees different documents in the (supposedly) read-only share.