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.
Best Answer
No, you don’t need to log in to start a process running as a given user. Logging in is a user-space construct; the kernel doesn’t care about that. There are multiple examples of this; for example, cron jobs can run as any user, without that user being logged in.
To address your specific questions:
initprocess, thankfully (imagine handling a fleet of thousands of servers and millions of VMs otherwise);