Precedence of user and group owner in file permissions

The thing is, I always thought these permissions collapse on each other, starting with the most general one (other -> group -> user).

If it was the case then “other” permissions would apply to everyone.

In other words, if o=rwx who cares what the persmissions for group and user are?

That's different from your previous sentence. Here you're implying that the permissions are or'ed together, e.g. that userX has the read permission if userX owns the file and the file is user-readable, or if a group that userX belongs to owns the file and the file is group-readable, or if the file is other-readable. But that's not how it works. In fact, o=rwx means that the rwx permissions apply to others, but it doesn't say anything about entities that are not others.

First, it doesn't directly matter which groups a user belongs to. The kernel doesn't have a notion of users belonging to groups. What the kernel maintains is, for every process, a user ID (the effective UID) and a list of group IDs (the effective GID and the supplementary GIDs). The groups are determined at login time, by the login process — it's the login process that reads the group database (e.g. /etc/group). User and group IDs are inherited by child processes¹.

When a process tries to open a file, with traditional Unix permissions:

• If the file's owning user is the process's effective UID, then the user permission bits are used.
• Otherwise, if the file's owning group is the process's effective GID or one of the process's supplementary group ID, then the group permission bits are used.
• Otherwise, the other permission bits are used.

Only one set of rwx bits are ever used. User takes precedence over group which takes precedence over other. When there are access control lists, the algorithm described above is generalized:

• If there is an ACL on the file for the process's effective UID, then it is used to determine whether access is granted.
• Otherwise, if there is an ACL on the file for the process's effective GID or one of the process's supplementary group ID, then the group permission bits are used.
• Otherwise, the other permission bits are used.

See also Precedence of ACLS when a user belongs to multiple groups for more details about how ACL entries are used, including the effect of the mask.

Thus -rw----r-- alice interns indicates a file which can be read and written by Alice, and which can be read by all other users except interns. A file with permissions and ownership ----rwx--- alice interns is accessible only to interns except Alice (whether she is an intern or not). Since Alice can call chmod to change the permissions, this does not provide any security; it's an edge case. On systems with ACLs, the generalized mechanism allows removing permissions from specific users or specific groups, which is sometimes useful.

Using a single set of bits, rather than or-ing all the bits for each action (read, write, execute), has several advantages:

• It has the useful effect of allowing removing permissions from a set of users or groups, on systems with ACLs. On systems without ACLs, permissions can be removed from one group.
• It is simpler to implement: check one set of bits, rather than combining several sets of bits together.
• It is simpler to analyse a file's permissions, because fewer operations are involved.

¹ _{They can change when a setuid or setgid process is executed. This isn't related to the issue at hand.}

The more specific permissions take precedence over the less specific.

userX in groupX

fileX userX:groupX ---rwx----

Since you are the the owner of the file you will be granted only owner permissions. The owner has no permissions. Thus, you cannot do anything. Had you not been the owner of the file and a group member then group permissions would apply.

Please read this section of the wiki page

https://en.wikipedia.org/wiki/File_system_permissions#Classes

-rwxrw---- means the owner has read, write and execute permissions, the group has read and write, and others have no permissions.

The permissions you provided give the group 'groupX' permissions to read, write and execute the file. If you are a member of the group "groupX" but not the owner of the file these permissions will apply to you.

In this case I am assuming you are indeed the owner of the file. Only the permissions set for the owner will then apply to you. Of course the owner is able to override or change the permissions on the file. The group, however, can not do this. For example vim will prompt you to confirm if you are writing to a file that you don't have write permissions to but are the owner of.

I usually read permissions from left to right. Am I the owner? If yes, the owner permissions apply. If not; am I a member of the group? If yes, group permissions apply. If not, then the permissions for "Other" apply to me.

In some cases it is useful to be the owner of a file but not have write permissions. It protects you from accidentally deleting or modifying the file. Personally I have set the permission 400 on all my template files, just to make sure I don't modify them by accident. The same goes for execute permissions.