Project

General

Profile

Actions

Bug #76273

closed

[7.6.7] User file/directory permissions overwrite permissions of group mounts

Added by Christoph Gross almost 8 years ago. Updated about 4 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
-
Target version:
-
Start date:
2016-05-23
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
7
PHP Version:
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

Description

  • Given we have a group "Redakteur" and this group has a mount "RedaktFiles" without the permission to delete folders
  • Given we have a user of this group which inherits its mounts from the "Redakteur" group
  • Then I would expect Typo3 to ignore the users file operation permissions unless a file mount was specifically added to this user
  • Instead Typo3 only looks at the users file operation permissions and ignores the group file operation permissions

Otherwise group permissions for file operations are useless because after user creation they are no longer enforced. And to change file operation permissions the Admin of the site would need to edit every single user. Typo3 should distinguish between two cases when enforcing file permissions:

Case 1: User inherits File Mount from Group => Users file operation permissions are ignored for that mount and the groups permissions take precedence
Case 2: User has selected File Mount (regardless of group File Mounts) => User file operation permissions take precedence over group file operation permissions for this file mount

Actions #1

Updated by Nicole Cordes over 7 years ago

Hi Christoph,

Thank you for your report. By reading your description I don't understand how your user is created. Can you please give a step by step explanation. Currently TYPO3 overwrites to permission from user to group. This is the intended way.

Otherwise it would not possible to give specific access to just one user.

Actions #2

Updated by Riccardo De Contardi about 6 years ago

Some tests performed with TYPO3 9.2-dev (latest master)

Test 1

1) Set a be usergroup: with a filemount and
- give all permissions to directories
- give all permissions to files

2) create a be user, assign it to the group created at 1) , check "Mount from group: File Mounts"
- give ONLY "read" permission for files and directories

switch user to the user created at 2) and visit a folder (with some files) in the filemount

result: the user can do everything, so the usergroup permissions seem used

Test 2

1) Set a be usergroup: with a filemount and
- give all permissions to directories except delete folder
- give all permissions to files except delete files

2) create a be user, assign it to the group created at 1) , check "Mount from group: File Mounts"
- give ONLY "delete" permission to directories and files

result: the user can delete both files and directories

Considerations

The behavior observed makes me think that the permissions from groups and users are somehow "merged"; I guess that the explanation is: in group/user permissions the "unchecked" state does not mean "deny", but it means "not set". I think it is coherent with the result of the tests.

Is this the expected behavior?

p.s. I guess that a consequence of this behavior is that it is impossible to have a user with less privileges than its group. For example it is impossible that a group can delete files, while its user cannot do that

Actions #3

Updated by Susanne Moog about 4 years ago

  • Status changed from New to Closed

Yes, the last comment is actually the intended behaviour. Rights / Permissions here are additive, meaning if the group is allowed to read and the user to write in combination she is allowed to do both. It's not so much "which permissions count" but more a "has any of the permission layers the corresponding access right" - as example for writing files: first, we look at the user, second at the group, then maybe at the parent group - if any of them allows writing, the user is allowed to write.

You can solve this issue by building your rights from bottom to top - basic groups with minimal rights, editor groups with more rights incorporating the basic groups and - if necessary at all - additional rights directly in the user record. My recommendation would be to remove all settings that may be configured in a group from the user.

Actions

Also available in: Atom PDF