The concept of Linux/Unix groups can be confusing. But let's try to unpack that.
Files and directories have both an owner and a group (or a "group owner" as you put it.) They also have three sets of rwx permission bits, one for user, one for group and one for other. Additionally, they have three more bits of permissions: setuid, setgid and sticky. The user and group of a file or directory are internally stored as an UID and a GID, which are unsigned integer numbers that serve as internal identifiers for users and groups.
Users in the system have a UID and a GID (typically set in the /etc/passwd file), the GID setting from that file is used to indicate the primary group of an user. Additionally, an user may belong to more groups (typically configured in the /etc/group file, which lists additional users for each group in the system.)
You can check your user's UID, GID, primary group and additional groups with the id command, which will list all this information for the user running the command.
When you try to access a file or directory, the system will try to validate your access based on the permission bits. In particular, it will start by looking at whether to use the user, group or other bits. If your UID matches exactly the UID of the user accessing the file, then the "user" bits will be used. For the group, if either your primary group matches the group of the file, or if any of the additional groups (as reported by id) matches that group, then the "group" bits will be used. Otherwise, if none of those match, the "other" bits will be used.
Meaning of permissions for files are fairly straightforward, r means you can open the file for reading, w means you can open that file for writing (thus modify its contents) and x means you can run this file as an executable (whether it's a binary or a script.)
For directories, it's a little more subtle. r means you can list the files in that directory (for example, with ls /path/to/dir), w means you can create new files in that directory (or delete existing files from that directory.) But you need x to be able to access any of the files in that directory, if you don't have x on a directory, you can't cd to that directory and you can't really open files inside that directory, even if you know they exist. (This allows for quirky setups, where with r but without x, you can list the filenames but you can't open any of the files, while with x but without r you can open files in the directory only if you know their names already, since you can't list the filenames in the directory.)
Assuming you have permissions to create a new file in a directory, a new file that you create will have your user as the owner and by default it will have your primary group as its "group owner". But that's not always the case!
Remember I mentioned the setgid bit earlier on? Well, if a directory has the setgid bid set (you can set it with chmod g+s /path/to/dir), then new files created in that directory will inherit the group of the directory itself, rather than the primary group of the user that creates it. Furthermore, if you create a new subdirectory under such a setgid-enabled directory, the subdirectory will also have the setgid bit enabled. (That is necessary in order to preserve the group-inheritance property for the whole subtree.)
This setgid bit on directories technique is quite useful to implement shared directories. We'll get to that shortly.
One more note of interest is that the Unix systems in the BSD family (such as FreeBSD, NetBSD, OpenBSD) always behave as the setgid bit is set on a directory. In that way, the primary group of a user is somewhat less meaningful, since being the group during file creation is typically the most visible feature of this group.
Another concept of interest is the "umask", which is a set of bits that gets "masked" when a new file or directory is created. You can check your umask in the shell by using the umask command and you can also use that command with an argument to modify the current umask. Typical values are umask 002, umask 022, umask 027, etc.
The bits in the umask refer to the rwx bits and the three octal digits map to the user, group and other bits in a permission mode. So umask 002 will preserve all the bits for user and group (0 means no masking), while they'll block the w bit for other (2 is w.) They'll keep files user and group writable, but only readable by others. umask 027 on the other hand, will have writable only by the user, only readable/executable but not writable by group, and no access for other (7 means masking all of rwx.)
The umask is used every time a new file is created. Applications typically specify the permissions they would like, normally in the most liberal way, so that the umask can restrict that to more realistic permissions. For instance, normal applications will ask that files are created with 0666 (rw-rw-rw-) permissions, expecting the umask will drop at least the world-writable bit. Directories will be typically created with 0777 (rwxrwxrwx), assuming the same.
So how can we put this all together?
The setup typically used by Red Hat based Linux distributions (such as RHEL, CentOS and Fedora) is a pretty flexible one, worth looking into.
For each user that is created, a group of the same name is created too (typically with a GID matching the UID of the user) and that group is set as the primary group of that user. That group is meant to contain only the user by the same name. So files of my user are typically created as filbranden:filbranden, with my own primary group gating the group permission bits.
Since the group is essentially the same as just the user itself, the umask is set to 002, which means that all files and directories will be group-writable by default.
So how do you lock down directories to make them private? Simple, just remove the permission bits for "other" from the top level directory. For example, if I use chmod 770 ~ (or 700 is also fine, 770 works because the primary group is my own), no other user will be able to access any of the files under my home directory. That the files inside there have read or execute bits for "other" doesn't matter since by missing the x bit on the top directory itself means they'll never be able to traverse that one.
So how do you implement shared directories? Simple. Start by creating a group and adding all users who are meant to collaborate on that project to this group. Next, create one (or more) directories for that project. Set the "group owner" of the directories to the group you just created. Finally, enable the setgid bit on these directories. All the members of that group will be able to create files in those directories. Since they all have umask 002, the files they create will be group-writable. And because of the setgid bit in the top directory, all the files will be owned by the shared group (and not the per-user primary groups.) Which means users in the group will be able to modify files that were created by other members of the group, since they'll have write permissions to those files.
These shared directories can be world-readable (by keeping the r and x permissions for "other" in the top directory), or can be private to the group (by removing those permissions.)
That's the gist of it. How Unix/Linux permissions typically work and the rationale for why they work in this way.
There are, of course, many caveats. Many of these settings (such as the umask) exist in different sessions and it's possible they get out of sync. Adding a user to a group means they typically need to log in again for the change to have effect. While creating a file in a setgid-bit enabled directory causes the group of the directory to be inherited, moving an existing file into that directory doesn't typically change ownership (so you may end up with files in the group share that are not modifiable by other members of the group.) Semantics around deleting files can be somewhat tricky as well.
Modern Unix/Linux systems keep all the logic behind users, groups, file ownership. But they typically also include additional mechanisms to enforce permissions, such as extended file ACLs, which can be much more granular in allowing read/write access to directory trees and do not suffer from many of the issues with basic permissions listed above.
11You're not the sole user, and you shouldn't be logging in as the superuser (
root). Trycat /etc/passwdto see a list of users. – chrylis -on strike- – 2020-02-24T16:38:32.537I can't think of any situation in which
-wxwould be a useful permission flag. – skyler – 2020-02-24T21:51:38.8901@skyler: the closest you can get to making "drop box" directory using just Unix permissions (if combined with +sticky bit) – user1686 – 2020-02-25T11:45:22.813
If you are unsure of the purpose of groups, just imagine breaking down the company you work for into groups like sales, manufacturing, HR, management, etc. Obviously, workers, like manufacturing, shouldn't look at sales or accountancy financial files; only management should get to update to other files (like employee reviews), etc, etc Some groups may be able to read, and others to update. E.g management can look at sales figures, but may not update them. Once you understand it in real world terms it should be easier to understand the excellent technical explanations which others give below. – Mawg says reinstate Monica – 2020-02-26T08:05:27.210
Run
ls -land inspect the 3rd column, that is the group. (Other answers are focusing on ACLs, so I thought I'd add in the basic version for clarity) – GammaGames – 2020-02-26T18:38:14.220