One thing I've noticed in a lot of recent distros is that users all have their own groups with the same name as their user name. What's the purpose of that? Groups are made to group users together in some ways, such as users, management, IT, etc. Seems pointless to have all these single-user groups. I seem to recall Unix systems before did have everyone's default group be users.
Why does every user have their own group
groupusers
Related Solutions
The reason (the only reason, as far as I know) to put users in a group of their own is to make umask 002 or umask 007 a sensible default.
The umask is a mask for the default permissions of newly created files. The meaning of the digits are the same as in chmod; the first digit is for the user, the second for the group, and the third for others. If a bit is 1 in the umask, it is removed (masked) from the permissions of the newly created file. For example, if an application creates a non-executable file with no particular privacy requirement¹, it will pass 666 as the file permissions, and the application of the umask 002 will result in a file with permissions 664 (0666 & ~002 in C-like notation), i.e. a file which is readable by everyone and writable only by the user and group (rw-rw-r--).
With the umask 022, files are world-readable by default but only writable by their author. With the umask 002, files are additionally writable by the group that owns them. If users's primary group is one where they are the only user, and the umask is 002, then:
- By default, files are only writable by their author, because although the permissions are
rw-rw-r--, there is no other user in the group that has write permissions. - To allow a file to be modified by members of a group, the author only needs to make it owned by that group with
chgrp. This can even happen automatically if the file is created in a directory with the setgid bit or an equivalent ACL.
The advantage over the 022 umask is that in that setting, in order to make a file editable by users, the author must do two things: set the group, and extend the permissions (chmod g+w). People tend to forget this second step (or sole step, in a setgid directory).
¹ Examples of files with particular privacy requirements: encryption keys; emails; any file in a public directory such as /tmp.
Who should own the files that already exist? I was thinking either root or creating a set of dummy users corresponding to the groups.
Leaving them owned root but belonging to a common group, presuming the files are masked 0002 (i.e., are group writable) has a little bit of an advantage in terms of preventing them from becoming accidentally reowned if you create users to match the groups and the people who are in the groups can log in as that user. I'm referring to accident here because of course a malicous user in the group will just be able to delete the files in any case. But if they are owned root (or any other user that is not the group), then while someone in the group can still write to them (and thus delete them), they won't be able to reown or modify the permissions such that other members of the group won't be able to subsequently access the file.
Using a group but no fixed owner (i.e., files can be owned by anyone, but should be in the correct group with group permissions) has an advantage if users will be creating files (see below).
Creating new users just to match the groups will probably create more potential problems than it actually solves. If using group permissions works, stick with that. You can also create a little command for the superuser:
#!/bin/sh
chown -R root:groupx $1
chmod -R g+w $1
And use it foo /some/directory. This will ensure everything in the tree is owned root, with group groupx, and group writable.
There is a potential problem using root as the owner if root then adds the setuid bit to a file, but I believe only owner can do that. If you are really worried, create a dummy user -- but not one that matches the group. One that has no privileges but no one can use.
There is one further issue with users creating new files, which by default will be owned by them. They will be able to change it to the correct group, which will make the file accessible to others, but they won't be able to change the owner. For that reason, and because people may forget, you may want to run foo /some/directory at regular intervals or opportune moments (e.g. when no one is logged in, since changing the ownership may affect software which has the file open).
Taking the last paragraph into account, you could just say the owner does not matter at all, only the group is important. In that case the foo command should use:
chgrp -R groupx $1
instead of chown.
where should I put the files
Creating a /home/groupx is absolutely fine even if groupx is a group and not a user. The only potential issue would be if you then go and create a user with the same name -- but you don't want that anyway. Put the files there and foo /home/groupx.
If you don't want users to be able to create files, set the directory 755. They will still be able to modify files owned by their group.
Best Answer
Essentially, it's part of a strategy to mitigate some security concerns while allowing users a simple way to collaborate with less permission hassles.
Linux systems have what's called a umask, which dictates file and directory permissions assigned on creation. By default, this umask is usually 022 which creates files with 644 permissions (owner read/write, group read-only, other read-only) and creates the restrictive settings normally applied to new files and directories.
Unfortunately, the lack of read/write for the group means that you have to rely on the person who created the file to grant proper permissions for a group to edit it (and users are not always reliable regarding this).
Part of the way to help solve this is to set a umask of 002 which results in files with 664 permissions (owner read/write, group read/write, other read-only). But this could have unwanted side effects (e.g. team members could edit each others private files dependent on default groups). So each each new user becomes part of a default group with just one user (emulating the 022/644 scheme).
More on how this helps collaboration: https://security.ias.edu/how-and-why-user-private-groups-unix