Edit: I didn't realize that the owner of a file can chmod
the file no matter what the permissions. This renders the situation of owner permissions being less than group permissions useless, as the owner can give themself more permission.
So as far as I can tell, there isn't an elegant solution to having a shared group folder, leaving you with the following options:
- Deny execute permission for "others" on the folder (
chmod o-x test
), so when somebody is removed from the group, they won't be able to read/modify/delete any files in the folder. A side effect of this is that no users outside the group will be able to read the files. - Allow "others" to read the folder. When you remove somebody from the group, change the owner of all the files they owned. e.g:
chown -R nobody test
.
From what I can tell, it would be very useful to have owner/group/other permissions ORed together. This way you can set owner permissions to less than the group permissions when you want to share files among a group and don't want the owner to make a difference (or similarly for group/other).
Currently when you set owner permissions to less than group permissions, the owner of the file is restricted, even when they belong to the group. Wouldn't it be better for basic permissions to be ORed together, with the option of using setfacl
to restrict access for particular users? I essentially want to know:
- Are there any/many cases where restricting access for the owner of the file is particularly useful?
- Is ORing a better solution, but we're stuck with the current model due to legacy?
I'm not suggesting that owner permissions should be removed. See here for reasons why owner permissions exist: Is there a reason why 'owner' permissions exist? Aren't group permissions enough?
If you are not convinced that ORing the permissions would be particularly useful, you may read below, otherwise stop here.
Here are 2 scenarios showing the problems of attempting to share files among somegroup
, with user1
being an arbitrary user belonging to this group.
In scenario 1, removing a user from a group doesn't deny them access to the files and folders they still own. In scenario 2 we attempt to solve this by lowering the owner permissions below group permissions, but then of course, as per the title, if you are both the file owner and in the group, the (lower) owner permissions are used.
Scenario 1
Basic permissions allow members of a group to share files, but after removing a user from the group, extra work is necessary to deny them access to those files.
As root
, run:
mkdir test
chgrp somegroup test
chmod 2775 test
setfacl -d -m u::rwx,g::rwx,o::rx test
Output of getfacl test
:
# file: test
# owner: root
# group: somegroup
# flags: -s-
user::rwx
group::rwx
other::r-x
default:user::rwx
default:group::rwx
default:other::r-x
As user1
, cd to test
, and run:
mkdir test2
As root
:
deluser user1 somegroup
Ideally, removing a user from the group should be enough to deny them permissions inside group directories, but user1
still has full access in the test2
directory. We have to perform chown -R
on the directory, and any other somegroup
directories on the system, leaving room for error.
Scenario 2
Without knowing the details of file permissions, one may think that the easy solution is to restrict permissions for the owner of the file. But this prevents members of the group from modifying files that they create.
As root
, run:
mkdir test
chgrp somegroup test
chmod 2575 test
setfacl -d -m u::rx,g::rwx,o::rx test
Output of getfacl test
:
# file: test
# owner: root
# group: somegroup
# flags: -s-
user::r-x
group::rwx
other::r-x
default:user::r-x
default:group::rwx
default:other::r-x
now as user1
, cd
to test
and run:
echo hi >> test2
echo hi >> test2
and of course, you get Permission denied
because user1
is the owner of the test2
file. Even though your group has permission to modify the file, you are denied access because only the owner permissions are checked.
setfacl
for restricting permission for specific users and groups, so flexibility is not lost, but only increased by the new possibilities. – Zantier May 07 '15 at 11:19For Scenario 1: One "catch" in your examples is that you've removed the user from a group, but did that user exit his/her shell and login again? If not, they still have that group membership.
For Scenario 2: I don't see this happening, but I'm not using ACLs. Without the ACLs it works as expected.
– Otheus May 07 '15 at 12:43test2
directory, it will be given default permissions. Runsudo chmod 075 test2
, and you will not be able tocd test2
. – Zantier May 07 '15 at 13:15root
or some other non-member of the group? – Chris Davies Jun 22 '15 at 08:38chmod o-x
once, which may not be desirable, else you need to remember tochown -R
after each removal. – Zantier Jun 23 '15 at 09:03drwxrwx---
(i.e770
) and then you don't need to worry about removing permissions from content. You do need to consider the users'umask
setting though -002
would be better than the default022
. – Chris Davies Jun 23 '15 at 09:17chmod o-x
option. ACLs can be used to overrideumask
. – Zantier Jun 23 '15 at 09:23