Permission issue

[Mululu]

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

1. Create a group folder and assign 2 groups.

2. Group 1 read, write

3. Group 2 read, write, delete

4. Try deleting folder with user in group 2

Expected behaviour

Users in group 2 should be able to delete

Actual behaviour

User from group 2 cannot delete because he is also in group 1 and is not allowed to delete group 1. The higher permission in this case, allowing deletion, should override the deletion note

Nextcloud Hub 8 (29.0.0)

[XueSheng-GIT]

Just tried with my NC29 test installation and followed your step. But actually user in group2 is able to delete.
Please double check whether the steps to reproduce are complete. Thanks.

[Mululu]

Hello,

I tried a few things back and forth, but unfortunately to no avail. This error is causing major problems in our organization. Steps I have now taken

• Deleted all permissions using the database and reset them >> no improvement

To narrow down the error further, I have done the following. 1 & 2 work as expected, but the error already occurs in 3., which is why I started the post.

1.

• The "Admin" group gets all rights for the main "Images" folder
• The "All" group does not get read rights

Result Users in the "Admin" group can see the "Images" folder // Users in the "All" group cannot // Users who are in the "Admin" group and in the "All" group at the same time can see the "Images" folder. >> Works

2.

• The "Admin" group gets all rights for the main folder "Pictures"
• The "All" group gets only read rights

Result Users in the "Admin" group can see the "Pictures" folder // Users in the "All" group can also see the "Pictures" folder // Users who are in the "Admin" group and in the "All" group at the same time can see the "Pictures" folder. >> Works

3.

• The "Admin" group gets all rights for the main folder "Pictures"
• The "All" group gets only read rights
• The "All" group is denied the "Read" right for a subfolder "Tablet". Result Users in the "Admin" group can see the "Pictures" folder and the "Tablet" subfolder // Users in the "All" group can also see the "Pictures" folder, but not the "Tablet" subfolder // Users who are in the "Admin" group and the "All" group at the same time can see the "Pictures" folder but not the "Tablet" subfolder >> Does not work as intended

Expectation: Users who are in the "Admin" and "All" groups at the same time should see the "Tablet" subfolder. So to speak, the "Admin" group's read permission should be higher than denying read rights to the "All" group.

I suspect that the permissions are not being passed on to the subfolders correctly!?

I hope I made it clear.

[XueSheng-GIT]

I assume you are mixing up general Access rights via Admin settings and ACL.
Please be more precise where you did those access restrictions. For me is also not clear whether you created nested groupfolders or not.
Maybe screenshots for the non-working example would be helpful (admin settings + ACL).

[Mululu]

The main rights are assigned in the settings. However, since there are also subfolders in the group folder that not everyone should see, the ACL permission is required there.

What you can also see in the following image is that rights are displayed incorrectly. The general rights from the settings (image above) are not displayed as standard (inherited) but are generally shown as denied. Main folder

But then shown as allowed again in the subfolder

Variant 2 (as described above)

Here the folder is visible to the Admin and Everyone groups, as defined in the basic settings. However, the display is incorrect as described above.
Subfolder "Tablet" visible according to basic setting rights
Display group "Admin" correct, display group All incorrect >> according to basic setting no share and no deletion rights. Read, write, create >> correct

Variant 3 (as described above)
Read rights for group All on subfolder Tablet denied

Result
Users who are in the group All can no longer see the folder >> so far so good. Users who are only in the group Admin can still see the folder >> just fine. However, if I add the user to the group All, the folder is no longer visible, even though they are still in the admin group and have reading rights.

Basically, the rights should be displayed correctly, otherwise it's stupid. And maybe you should be able to define the group's ranking. But that's not the main problem. Everything worked before the update to Nextcloud 29.

[XueSheng-GIT]

On the frist view I would say as expected. ACL deny does overwrite general permit. Try to add a ACL grant to read for Admin and double check again. But I assume that also deny acl does overwrite grand acl.
Maybe a more correct description: #2828

Regarding displaying of inheritance, I think there's already an issue for this (probably also a fix).

[XueSheng-GIT]

Please also double check whether your issue is a duplicate of #2812.

[fschrempf]

Maybe related or even fixed by: #2870

[Mululu]

On the frist view I would say as expected. ACL deny does overwrite general permit. Try to add a ACL grant to read for Admin and double check again. But I assume that also deny acl does overwrite grand acl. Maybe a more correct description: #2828

Regarding displaying of inheritance, I think there's already an issue for this (probably also a fix).

Unfortunately, I have to disagree with you because the regulations are such that approvals override refusals.

Maybe related or even fixed by: #2870

I'll look at it tomorrow

[Mululu]

So I have no idea what has changed in Nextcloud 29 or in the Groupfolder app, but something is wrong here. According to the documentation, the allow right should override the deny right. This has worked for me in the past and we have been using Nextcloud since version 25. And from now on it no longer works without any changes to the rights.

Maybe something has been messed up here? @#2902

What I can't find anywhere is what does occ config:app:set groupfolders acl-inherit-per-user --value true do?
Is this new or when was it introduced?
What happens if it's true? What happens if it's false? I couldn't see any change.

[chaosgrid]

I think this is the same issue as #2812 because in general, inherited "allow" permissions of a group A do not take precedence over explicit "deny" permissions of a different group B in the current folder while you are a member of both groups. This behaviour changed somewhere within the last year.