OCS Share API - "permissions" parameter has no effect

[timowevel1]

⚠️ 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.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

The OCS Share API doesnt work properly. One is not able to set the permissions, it always stays "17".

Steps to reproduce

1. Create Share Link via API with the desired permissions

Expected behavior

Permissions are set correctly

Installation method

Manual installation

Operating system

Debian/Ubuntu

PHP engine version

PHP 8.0

Web server

Nginx

Database engine version

MariaDB

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

Fresh Nextcloud Server install

Are you using the Nextcloud Server Encryption module?

Encryption is Disabled

What user-backends are you using?

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

Configuration report

No response

List of activated Apps

Only default apps, fresh install

Nextcloud Signing status

No response

Nextcloud Logs

No response

Additional info

No response

[jplitza]

I guess the problem is this else block:

server/apps/files_sharing/lib/Controller/ShareAPIController.php

Lines 569 to 586 in 62919ac

	if ($publicUpload === 'true') {
	// Check if public upload is allowed
	if (!$this->shareManager->shareApiLinkAllowPublicUpload()) {
	throw new OCSForbiddenException($this->l->t('Public upload disabled by the administrator'));
	}
	// Public upload can only be set for folders
	if ($node instanceof \OCP\Files\File) {
	throw new OCSNotFoundException($this->l->t('Public upload is only possible for publicly shared folders'));
	}
	$permissions = Constants::PERMISSION_READ |
	Constants::PERMISSION_CREATE |
	Constants::PERMISSION_UPDATE |
	Constants::PERMISSION_DELETE;
	} else {
	$permissions = Constants::PERMISSION_READ;
	}

It has been like that since the introduction of the API, but obviously ignores the permissions requested by the client. I'm not sure why that block is there at all, IMO it could simply be removed. But there may be a reason to cap the permissions to something applicable to files (like read & update?).

[timowevel1]

Still not fixed, I am not able to set the permissions. It doesnt matter which value the "permissions" parameter has, it always gets permission "17"

[jplitza]

@timowevel1 Commit 628b0d8 is only present in the beta versions of v26. Do you have those installed?