Why, by design, are group permissions ignored for the owner of a file?

Question

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.