So I am trying to understand the concept of groups and permissions in Linux, and am thoroughly confused. On my laptop, where I am the sole-user and thus super-user, I understand what it means to change file permission on text-files (chmod +x) to make it executable, or to change read-write permission (chmod +/- rw)
But I don't really get the concept of a group. From what I've gleaned a group is just a bunch of users. (But does that mean a user can belong to multiple groups?) A group as I understand is basically meant to make it easier to set/unset rwx permissions wholesale for a bunch of users (i.e. the group).
But now on this website the author says:
There are three levels of permissions in Linux: owner, group and
other. The owner is the user who owns the file/folder, the group
includes other users in the file’s group and other just represents all
other users who are not the owner or in the group.
Does that mean that in addition to a file having an owner (i.e. the userid of the person who created the file) there is also a "group owner" for that file? And is this group typically one of the groups
the file-owner belongs to?
What if I have three groups A,B,C on my system and want to set permissions rw-, -wx, r-x respectively on the system?
Asking the questions above very likely shows that my mental model of what a "group" and "group permission" in Unix is, is flawed.
I've tried reading up a bunch of articles but I seem to be missing something fundamental in understanding the notion of group and group permission.
Can someone give me a succinct explanation or refer me to some clearer articles on this topic?
Best Answer
Yes, and yes.
One way it makes setting permissions much easier is when group needs access to many files or folders scattered around the system.
For example, whenever a new user joins, you would otherwise need to find all those files one by one and try to guess things like "if users A,B,C have access, then user D should be added". But if those permissions simply list a group name, then you don't need to update them at all – instead you just add the user to a group, done.
(It's not limited to just file permissions – some system services may also be configured to grant access to a group instead of individual users, with the same advantages as here.)
Yes. Each user has a "primary group", and newly created files belong to that group. However, even non-root users can use chown/chgrp to reassign their own files to any group that they currently belong to.
(There's an exception: If the directory has the 'setgid' bit set, then newly created files in it inherit the directory's group, not the creator's. This is closer to how Windows NTFS works by default.)
Of course, this "group owner" system is a bit limiting when files can only have one group at a time. See the next section about that.
Then you use another feature called "ACLs" (access control lists), which – as the name implies – allows you to specify an arbitrary list of users and groups to give access to.
Linux supports the POSIX ACL format, which is mostly a straightforward extension of the existing model. That is, if you first rewrite the existing permissions as:
now you can use
setfaclorchaclto add your three additional groups as:Note to avoid confusion: POSIX ACLs try to remain compatible as much as possible with traditional chmod, but this leads to a surprising feature. As soon as you add ACLs to a file, the "group" field in
ls -lwill instead start showing something called a 'mask', and a command likechmod g-wwill deny write access to all ACL entries, not just to the "owner group".Why does Linux, or even Unix, use the 'owner/group/other' categorization if it could just use ACLs instead? It does because this simple categorization predates ACL support by decades.
Unix originally went for the simple approach, as most other operating systems did at the time – either due to disk space constraints (permission bits fit in just two bytes), and/or deliberate design decision (Multics may have had elaborate ACLs at the time, but plenty of things in Unix were intentionally simplified).
Eventually the APIs became set in stone – new ones could be added, but the existing "chmod" could not be changed, because programs already expected it to work in a certain way. (OpenVMS too had to keep its similar permission-bit system even after adding ACLs.)
In addition to that, unfortunately it's the only system cross-compatible between all of the Unix-like operating systems. Some other Unixes (e.g. FreeBSD, Solaris) may use a quite different ACL format, and yet others (OpenBSD) have no ACL support at all. Compare also to Windows, where all file protections are ACL-based.