Users, groups, and the three permission classes

The kernel keeps bits, not a guest list

UNIX does not store a list of who may touch a file. It stores nine bits in the file's inode, and it works out which three of them apply to you by asking two questions in a fixed order: are you the file's owner? If not, are you a member of the file's group? If neither, you are other. The three classes are written u (user — meaning the owner), g (group) and o (other), with a as shorthand for all three.

Once you have logged in, the kernel has stopped caring about your login name. You are an integer UID, and you carry a set of integer GIDs. Every comparison it makes is between those integers and the two owner fields recorded in the inode. root is UID 0, and root skips the check entirely — permission bits are advice to root, not a wall.

Where group membership is written

Every user belongs to at least one group and may belong to several. Membership is assigned by the administrator, and it is recorded in two different places, which is where most of the confusion lives:

• Your default (primary) group is the GID field of your own line in /etc/passwd. You are in that group without being named anywhere else.
• Your supplementary groups are the ones that list you by name in /etc/group.

/etc/group has one line per group and four colon-separated fields: the group name, a password placeholder, the numeric GID, and a comma-separated member list. That last field holds only the supplementary members.

Worked example — reconciling three commands on one account

The account is ada. Three commands, run one after another, and every line of output reconciled against the other two:

$ id
uid=1043(ada) gid=1200(students) groups=1200(students),1450(dev)
$ groups
students dev
$ grep -E '^students:|^dev:' /etc/group
students:x:1200:
dev:x:1450:ada,amara,tobi

Read them together. id reports one UID (1043) and two GIDs. The first GID, 1200, is labelled gid= rather than appearing only under groups=: that is the default group, and it came from the GID field of the /etc/passwd line for ada. The second, 1450, is supplementary.

Now look at /etc/group. The dev line names ada in its member list, which is exactly how the supplementary membership was created. But the students line ends in a colon with nothing after it — an empty member list — and ada is in students anyway. The empty field does not mean an empty group. It means every member of students holds it as their default group, so nobody needs to be listed.

First match wins — the classes are never combined

Here is the part that costs marks. Suppose report.txt is owned by ada, its group is dev, ada is a member of dev, and its mode is rw-rwx---. What may ada do with it?

Read and write. Not execute. The kernel found a match on the very first question — the UID equals the owner's — so it applied the owner triple, rw-, and never looked at the group triple at all. The classes are checked in order and the first one that matches decides; they are not unioned, and the more permissive one does not win. Being in the group makes no difference to the owner, which is why chmod g+x on your own file changes nothing about what you can do with it.