Granting 775 permissions on a directory doesn't automatically mean that all users in a certain group will gain rwx access to it. They need to either be the owner of the directory or to belong to the directory's group:
$ ls -ld some_dir
drwxrwxr-x 2 alex consult 4096 Feb 20 10:10 some_dir/
^ ^
| |_____ directory's group
|___________ directory's owner
So, in order to allow both alex and ben to have write access to some_dir, the some_dir directory itself must belong to the consult group. If that's not the case, the directory's owner (alex in your example), should issue the following command:
$ chgrp consult some_dir/
or to change group ownership of everything inside the directory:
$ chgrp -R consult some_dir/
This will only work if alex is a member of the consult group, which seems to be the case in your example.
This will not allow ben to access all of alex's directories for two reasons:
- Not all of alex's directories will belong to the
consult group
- Some of alex's directories may belong to the
consult group but alex may not have chosen to allow rwx group access to them.
In short, the answer depends both on group ownership and on the group permission bits set for the directory.
All of this is provided you don't use any additional mandatory access control measures on your system.
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
History
Originally, Unix only had permissions for the owning user, and for other users: there were no groups. See the documentation of Unix version 1, in particular
chmod(1). So backward compatibility, if nothing else, requires permissions for the owning user.Groups came later. ACLs allowing involving more than one group in the permissions of a file came much later.
Expressive power
Having three permissions for a file allows finer-grained permissions than having just two, at a very low cost (a lot lower than ACLs). For example, a file can have mode
rw-r-----: writable only by the owning user, readable by a group.Another use case is setuid executables that are only executable by one group. For example, a program with mode
rwsr-x---owned byroot:adminallows only users in theadmingroup to run that program as root.“There are permissions that this scheme cannot express” is a terrible argument against it. The applicable criterion is, are there enough common expressible cases that justify the cost? In this instance, the cost is minimal, especially given the other reasons for the user/group/other triptych.
Simplicity
Having one group per user has a small but not insignificant management overhead. It is good that the extremely common case of a private file does not depend on this. An application that creates a private file (e.g. an email delivery program) knows that all it needs to do is give the file the mode 600. It doesn't need to traverse the group database looking for the group that only contains the user — and what to do if there is no such group or more than one?
Coming from another direction, suppose you see a file and you want to audit its permissions (i.e. check that they are what they should be). It's a lot easier when you can go “only accessible to the user, fine, next” than when you need to trace through group definitions. (Such complexity is the bane of systems that make heavy use of advanced features such as ACLs or capabilities.)
Orthogonality
Each process performs filesystem accesses as a particular user and a particular group (with more complicated rules on modern unices, which support supplementary groups). The user is used for a lot of things, including testing for root (uid 0) and signal delivery permission (user-based). There is a natural symmetry between distinguishing users and groups in process permissions and distinguishing users and groups in filesystem permissions.