1

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.

Zantier
  • 161
  • In general it is considered good to have the 'most restrictive' permissions effective. If you mean to deny access from the owner, that is honoured. If a owner is not set at all (which is not possible as far as I know) you could have access since only the group is defined granting access. – Lambert May 07 '15 at 09:48
  • 1
    If owner and group permissions should be ORed together, why not also "other" permissions? Because that's not useful. Your suggestion would reduce flexibilty, why would you want that. – wurtel May 07 '15 at 11:02
  • If you were to have owner and group permissions ORed together, then indeed "other" should be ORed too. Then when you create a file with only "other" permissions, the intention is clear that the user and group with which this file was created is not to be seen as important. You could still use 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:19
  • 1
    I think your question is unanswerable because you are combining Posix ACLs with Posix users/groups, which IIRC have different semantics (and completely different history).

    For 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:43
  • @Otheus: ACL is designed to be used alongside basic file permissions as far as I'm aware. That catch is true, but I would leave it as a separate issue. For Scenario 2 without ACL, when you create the test2 directory, it will be given default permissions. Run sudo chmod 075 test2, and you will not be able to cd test2. – Zantier May 07 '15 at 13:15
  • The question you linked to already answers your question. Stating that there are now use cases that would work better if UNIX had been implemented differently doesn't change the answer to "why does UNIX work that way?". – Mikel May 21 '15 at 15:24
  • @Mikel: None of those answers touch on owner permissions being set to more restricted than group permissions. (Edit: Sorry, I just realized my latest edit had really bad wording in the first sentence - I've fixed it now.) – Zantier May 21 '15 at 16:02
  • You phrased the question "Why, by design, are group permissions ignored for the owner of a file?". The existing question already seems to answer that question perfectly. Adding "it would be better if it did something different" doesn't make it a new question as far as I can see. – Mikel May 21 '15 at 20:14
  • @Christopher: 1. With 2575, you can create a file in the folder, but then aren't be able to modify it. 2. This gives the same problem as scenario 1, where users are still able to modify the files they created after they are removed from the group. – Zantier May 22 '15 at 11:29
  • @Mikel: Group permissions being ignored for the owner of a file is only relevant when the owner is given less permission than the group, which as I said before is not touched on in the linked question and answers. – Zantier May 22 '15 at 11:33
  • If you want to manage a shared group folder, could you not just make the owner of the folder root or some other non-member of the group? – Chris Davies Jun 22 '15 at 08:38
  • @roaima: Indeed, the shared folder should be owned by a non-member. I wanted a really elegant solution that behaved nicely when removing a member from the group, but the closest you can get seems to be the first 2 bullet points in my question - chmod o-x once, which may not be desirable, else you need to remember to chown -R after each removal. – Zantier Jun 23 '15 at 09:03
  • Directory permissions drwxrwx--- (i.e 770) 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 default 022. – Chris Davies Jun 23 '15 at 09:17
  • 1
    @roaima Yeah, that's the chmod o-x option. ACLs can be used to override umask. – Zantier Jun 23 '15 at 09:23

0 Answers0