Is there a reason why 'owner' permissions exist? Aren't group permissions enough?

Question

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...".

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.