[Bug]: Share API default to wrong permissions

[schiessle]

⚠️ This issue respects the following points: ⚠️

• This is a bug, not a question or a configuration/webserver/proxy issue.
• This issue is not already reported on Github (I've searched it).
• Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• Nextcloud Server is running on 64bit capable CPU, PHP and OS.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

According to our documentation, when creating a public link with our API the permissions should default to "1" (read only) but it will be set to 17 (1 = read, 16= share). Luckily the combination doesn't hurt, but it is still wrong.

Also it seems that all permissions send along the request, e.g. curl -k -X POST -d "path=<path to folder>" -d "shareType=3" -d "permissions=4" -H "OCS-APIRequest: true" -u <user>:<password> http://<nc domain>/ocs/v2.php/apps/files_sharing/api/v1/shares get ignored even that "permissions" is a valid parameter and "4" would be a valid value for a folder (file drop)

Steps to reproduce

1. Create a public link with the OCS API ( curl -k -X POST -d "path=<path to folder>" -d "shareType=3" -d "permissions=4" -H "OCS-APIRequest: true" -u <user>:<password> http://<nc domain>/ocs/v2.php/apps/files_sharing/api/v1/shares)
2. check the result

Expected behavior

default permission is "1" if no permission is given, otherwise permission given by the user gets applied

Installation method

None

Nextcloud Server version

25

Operating system

None

PHP engine version

None

Web server

None

Database engine version

None

Is this bug present after an update or on a fresh install?

None

Are you using the Nextcloud Server Encryption module?

None

What user-backends are you using?

• Default user-backend (database)
• LDAP/ Active Directory
• SSO - SAML
• Other

Configuration report

No response

List of activated Apps

-

Nextcloud Signing status

No response

Nextcloud Logs

No response

Additional info

No response

[tfboy]

I found this issue, posted about it on the groups and was about to post it here as a bug but have been beaten to it! My other post here: https://help.nextcloud.com/t/ocs-share-api-options-and-defining-permissions-bug/161037

In my experimenting, I have also found out that the actual values set for permissions depends on whether, for a public share, you define publicUpload=true.

I can't understand why this variable exists when shareType allows you to define it as a public share. Maybe to be in addition?

Anyway, if the publicUpload is set to true, then the resulting permissions number is always 31, regardless of what you define.

If publicUpload isn't defined, then permissions seem to be set to 17 + whatever you define as the permission number. So, if for example, you set permissions=4, then the actual share is created with permissions set to 21.

I tried a negative number to see if I could "bring it down to 4", but that doesn't work.

@schiessle , when you say "Luckily the combination doesn't hurt, but it is still wrong.", I will have to disagree: in your case, as per mine, you want an upload only but the user gets read. That's a problem. I do not want one user being to read files in that share, only to upload. This, to me, is a big security issue!

Edit: schiessle reported this issue with NC 25. I'm having the same issue with NC 26.0.1.

[Pitastic]

I installed the update to 26.0.1 today and something has been fixed in this issue but not completly.

I am now able to mitigate this bug:

• Create a share with arguments path=xxx , shareType=3 and permissions=4
• Permissions will be READ and UPLOAD (which is not what I want, but it is not ALL anymore)
• Update the share with the given ID from above with arguments path=xxx and permissions=4 and voilà 😄

[joshtrichards]

Related: #17504

[susnux]

To give some insights what is happening here:

• if you set publicUpload the permissions are always overwritten with READ+MODIFY+DELETE
  • This flag is legacy and should not be used anymore so just do not use it.
• permissions will currently always contain READ
  • This is IMHO a bug and tracked here Create Share API not honoring "permissions" parameter #17504
  • You can work around this by create a share and after that update it with permissions being only CREATE (the update API endpoint works).