"Deny" Group permission prevails over "allow" User permission
slaver666 opened this issue · comments
How to use GitHub
- Please use the 👍 reaction to show that you are affected by the same issue.
- Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
- Subscribe to receive notifications on status change and new comments.
Steps to reproduce
- User has extended permission to the root folder. Group has read permissions to the root folder.
- User creates a folder inside root folder. The child folder inherits root folder permissions.
- User removes Group read permission to the child folder.
Expected behaviour
User must have all permissions to the folder.
Actual behaviour
User even doesn't see the folder any more.
Server configuration
Operating system:
Ubuntu Linux 22.04.3 LTS
Web server:
Nginx 1.25.3
Database:
PostgreSQL 15.5
PHP version:
8.2
Nextcloud version: (see Nextcloud admin page)
28.0.2
Group folders version:
16.0.3
Updated from an older Nextcloud/ownCloud or fresh install:
updated from 27
Where did you install Nextcloud from:
community edition from official site
Are you using external storage, if yes which one: local/s3/smb/sftp/...
no
Are you using encryption: yes/no
no
Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/Saml/...
Active Directory
Client configuration
Browser:
Google Chrome, Microsoft Edge
Operating system:
Windows 10, Ubuntu Linux 22
Logs
Can't see any log entries belonged to Group folders app
Web server error log
Web server error log
No errors in web server log
Nextcloud log (data/nextcloud.log)
Nextcloud log
[Uploading nextcloud.log…]()
Browser log
Browser log
Insert your browser log here, this could for example include:
a) The javascript console log
b) The network log
c) ...
Hi @slaver666,
Can you detail a way to reproduce the bug. This will allow me to see if it's the same bug as the one I found on my side.
Thx
@Jerome-Herbinet Do the Steps to reproduce from the OP not work for reproducing the issue? If not can you elaborate what result you see instead?
Steps to reproduce
1. User has extended permission to the root folder. Group has read permissions to the root folder. 2. User creates a folder inside root folder. The child folder inherits root folder permissions. 3. User removes Group read permission to the child folder.Expected behaviour
User must have all permissions to the folder.
Actual behaviour
User even doesn't see the folder any more.
Hi @slaver666, Can you detail a way to reproduce the bug. This will allow me to see if it's the same bug as the one I found on my side. Thx
Hi. I thought my "Steps to reproduce" are well described. I'm ready to give any information/screenshots if you need.
@Jerome-Herbinet Do the Steps to reproduce from the OP not work for reproducing the issue? If not can you elaborate what result you see instead?
Steps to reproduce
1. User has extended permission to the root folder. Group has read permissions to the root folder. 2. User creates a folder inside root folder. The child folder inherits root folder permissions. 3. User removes Group read permission to the child folder.Expected behaviour
User must have all permissions to the folder.
Actual behaviour
User even doesn't see the folder any more.
I read it again, and I think the description is good. Test and result are similar to mine.
I think this is one of the many issues which all describe the same kind of defect. The inherited permissions from the root folder are not taken into account when there is a deny rule for the subdirectory.
Please read through #1212 and other related reports and you might come to the same conclusion as me, which is that groupfolder ACLs are a total mess and pretty much unusable.
I am in the admin and in the employee group. When I restrict a permission for the employee group, I lose access to that folder. By adding me as person with all permissions, I still have no access. I am looking forward for a solution.
I just want to add that this behaviour definitely changed within the last year (not exactly sure when).
It is also easy to reproduce:
Make a folder which inherits read permission i.e. of an "admin" group.
Now explicitly deny read access to a "team_member" group to this folder, of which you are also a member. The deny entry now has priority over the inherited read permission of the "admin" group of the parent folder.
I assume this is not intended behaviour and I'm suprised this bug has not been fixed yet..
I also think this is related to or a duplicate of #2934
I think this issue is also fixed by following this post: #2934 (comment)
It is not a bug, but a feature which changed the default permission behaviour when there are inherited permissions.