22

I think I rather understand how file permissions work in Linux. However, I don't really understand why they are split into three levels and not into two.

I'd like the following issues answered:

  • Is this deliberate design or a patch? That is - was the owner/group permissions designed and created together with some rationale or did they come one after another to answer a need?
  • Is there a scenario where the user/group/other scheme is useful but a group/other scheme will not suffice?

Answers to the first should quote either textbooks or official discussion boards.

Use cases I have considered are:

  • private files - very easily obtainable by making a group per-user, something that is often done as is in many systems.
  • allowing only the owner (e.g. system service) to write to a file, allowing only a certain group to read, and deny all other access - the problem with this example is that once the requirement is for a group to have write access, the user/group/other fails with that. The answer for both is using ACLs, and doesn't justify, IMHO, the existence of owner permissions.

NB I have refined this question after having the question closed in superuser.com.

EDIT corrected "but a group/owner scheme will not suffice" to "...group/other...".

3
  • 1
    I don't really understand why you think group permissions would be enough. Imagine a situation where you want to allow your developers to have their own private files (configurations, etc), but also want to allow them to share code between each other. Having a devs group allows for this.
    – Chris Down
    Nov 12, 2012 at 20:45
  • 1
    @ChrisDown He's saying you'd make user foo a member of groups foo and devs, and assign shared files to the dev group and private files to the foo group Nov 12, 2012 at 21:06
  • 5
    While you're at it, why have world permissions instead of just an 'everyone' group that everyone is a member of? The answer is that the user/group/other permission setup was invented before ACLs.
    – Random832
    Nov 12, 2012 at 21:17

4 Answers 4

27

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 by root:admin allows only users in the admin group 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.

5
  • Excellent answer, and I enjoyed learning about older 'man's. However, I have some reservations about what you said. A simpler system, which can actually do almost (if not exactly) as much as ACLs, is let each of the 'rwx' permissions carry a group (rather than the other way around). That is, you'll have a read group, a write group and an execute group. If really needed for OS purposes, you can attach an owner to the file. That way you can also specify a special 'owner' group and an 'everyone' group. Other than hierarchy, I think this covers everything, including simplicity and orthogonality.
    – Yuval
    Nov 13, 2012 at 19:00
  • 1
    @Yuval What you're describing is an ACL system — the same as Linux's, except without the direct ability to assign permissions to a user. Nov 13, 2012 at 19:13
  • That might be. What I tried to emphasize is that currently each file record holds two IDs (group, owner) and a bitmask. Wouldn't it be more effective (again, the cost/gain argument) to just hold four IDs? (execute group, read group, write group, owner)
    – Yuval
    Dec 23, 2013 at 9:25
  • @Yuval Why four IDs? That would be a lot more restrictive than ACLs (because you would need root to define a group for every set), and hardly any more flexible than current unix permissions (distinguishing read from execute is extremely rare, and for write you'd often want the union of the read group and the write group). If you allow a list of groups for each permission, and a list of users for good measure (because there isn't always the right group, not all systems have a group per user), you've basically got Solaris/Linux ACLs. Dec 23, 2013 at 13:31
  • 1
    You argue that what I described is an ACL, but this means that the current Linux permission scheme is a handicapped ACL, that's allowed to have only one user record, one group record and one record for Everyone (to use Windows lingo). I suggested modifying the handicapped-ness by rearranging the semantics. Rather than prescribing entities, prescribe permissions. This might be how traditional ACLs are implemented - I don't know. The point is, it comes as minimal cost, in terms of storage and simplicity, compared to the current state, still orthogonal, but with the full expressive power of ACLs.
    – Yuval
    Jul 6, 2015 at 8:20
10

Is this deliberate design or a patch? That is - was the owner/group permissions designed and created together with some rationale or did they come one after another to answer a need?

The user/group/other permissions on a file are a part of the original Unix design.

Is there a scenario where the user/group/other scheme is useful but a group/owner scheme will not suffice?

Yes, virtually every scenario I could imagine where security and access control is important.

Example: You may want to give some binaries/scripts on a system execute-only access to other, and keep read/write access restricted to root.

I'm not sure what you have in mind for a file system permission model that has only owner/group permissions. I don't know how you could have a secure operating system without the existence of an other category.

EDIT: Supposing you meant here group/other permissions are all that would be needed, then I suggest devising some way to manage cryptographic keys or a way that only the right users can access their mail spool. There are cases where a private key may need strictly user:user ownership but other cases where it makes sense to give it user:group ownership.

private files - very easily obtainable by making a group per-user, something that is often done as is in many systems.

Granted that this is easily done, but it is just as easily done with the existence of an other group...

allowing only the owner (e.g. system service) to write to a file, allowing only a certain group to read, and deny all other access - the problem with this example is that once the requirement is for a group to have write access, the user/group/other fails with that. The answer for both is using ACLs, and doesn't justify, IMHO, the existence of owner permissions.

I have highlighted the part of your statement that seems to reiterate my point about the logical necessity for an other category in Unix file system permissions.

Such a file system design as you seem to be contemplating (from what I can tell) would either be insecure or unwieldy. Unix was designed by some very smart people, and I think their model gives the best possible balance of security and flexibility.

3
  • 1
    I think "group/owner" was a typo intended to be "group/other"
    – Random832
    Nov 12, 2012 at 21:31
  • Ah, you are probably right! In that case, I will add another counter-example. Nov 12, 2012 at 21:34
  • 4
    As you can read in The UNIX Time-Sharing System, written by Dennis M. Ritchie and Ken Thomson in 1974, originally, there were 7 bits for permissions: Also given for new files is a set of seven protection bits. Six of these specify independently read, write, and execute permission for the owner of the file and for all other users. (The seventh bit was the setuid bit). Nov 13, 2012 at 15:27
4

Is this deliberate design or a patch? That is - was the owner/group permissions designed and created together with some rationale or did they come one after another to answer a need?

Yes this is a deliberate design which has been present in UNIX since early days. It was implemented on systems where memory was measured in KB and CPUs were extremely slow by today's standards. Size and speed of such look-ups was important. ACLs would have required more space and been slower. Functionally, the everyone group is represented by the other security flags.

Is there a scenario where the user/group/other scheme is useful but a group/owner scheme will not suffice?

Permissions I commonly use for file access are: (I am using bit values for simplicity and because that is the way I usually set them.)

  • 600 or 400: User only access (and yes I do grant read only access to user).
  • 640 or 660: User and group access.
  • 644, 666 or 664: User, group, and other access. Any two level permission scheme can only handle two these three cases. The third would require ACLs.

For directories and programs I commonly use:

  • 700 or 500: User only access
  • 750 or 710: Group only access
  • 755, 777, 775, or 751: User, group, and other access. Same comments apply as for files.

The above are the most commonly used, but not an exhaustive list of permission setting I use. The above permissions combined with a group (sometimes with a sticky group bit on directories) have sufficed in all cases where I might have used an ACL.

As has been noted above, it is very easy to list the permission in a directory listing. If ACLs are not used I can audit access permissions with only a directory listing. When I work with ACL based systems, I find it very difficult to verify or audit permissions.

3

The user/group/other permission system was designed before ACLs were invented. It goes back to the early days of UNIX, so you can't say the problem should be solved with ACLs. Even if the concept of an ACL seems obvious, it would have involved a significant [for the day] amount of extra overhead to store and manage a variable amount of permission information with each file, rather than a fixed amount.

Using ACLs for everything also means you don't have a well-defined subset of the permission information that can be shown "at a glance". The output for ls -l shows the standard (user/group/other) permissions, the name of the user and group, and an additional notation (e.g. + or @ sign) on entries which have an ACL associated with them, all in one line. Your system would require it to identify the "top two" groups in the ACL to provide equivalent functionality.

As an additional point, a file still needs to have an owner in the UNIX model because UNIX ACLs do not provide for who is allowed to modify the ACL.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .