Skip to content
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

[Bug]: Top-most level file permissions are enforced recursively for nested shares #7223

Open
5 of 8 tasks
golanv opened this issue Sep 26, 2024 · 0 comments
Open
5 of 8 tasks

Comments

@golanv
Copy link

golanv commented Sep 26, 2024

⚠️ Before submitting, please verify the following: ⚠️

Bug description

Assuming a user share by UserA of the "Documents" directory where read-only access is given to another UserB, and if a nested share is created in "Documents/somefolder" with read-write permissions given to UserB. If UserB attempts to access the folder locally via "~/Nextcloud/Shared/Documents/somefolder", the Nextcloud client will enforce read-only permissions of the root share ("Documents"), rather than the read-write permissions of "somefolder". In order for UserB to write to "somefolder", it must be accessed via "~/Nextcloud/Shared/somefolder".

It seems that the Nextcloud client should enforce correct permissions of "somefolder" regardless of the path used to access it, which would match the behavior seen when accessing shares from the web client.

Steps to reproduce

  1. Create a share with read-only access to another user
  2. Create a new share in a subfolder of the share from step 1 with read-write access to the same folder
  3. Access the share using the absolute path locally.
    ...

Expected behavior

One would expect permissions of nested shares to always be consistent, regardless of the path used to access them.

Which files are affected by this bug

unknown

Operating system

Linux

Which version of the operating system you are running.

Gentoo

Package

Official Windows MSI

Nextcloud Server version

29.0.7

Nextcloud Desktop Client version

3.11.1

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

Updated from a minor version (ex. 3.4.2 to 3.4.4)

Are you using the Nextcloud Server Encryption module?

Encryption is Disabled

Are you using an external user-backend?

  • Default internal user-backend
  • LDAP/ Active Directory
  • SSO - SAML
  • Other

Nextcloud Server logs

No response

Additional info

No response

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant