Reasons behind the default groups and users on Linux

Question

Having a look at the default users & groups management on some usual Linux distributions (respectively ArchLinux and Debian), I'm wondering two things about it and about the consequences of modifying the default setup and configuration.

The default value for USERGROUPS_ENAB in /etc/login.defs seems to be "yes", which is reflected by the "By default, a group will also be created for the new user" that can be found in the useradd man, so each time a new user is created, a group is created with the same name and only this new user in. Is there any use to that or is this just a placeholder?

I'm feeling like we are losing a part of the rights management as user/group/others by doing this. Would it be bad to have a group "users" or "regulars" or whatever you want to call it that is the default group for every user instead of having their own?

Second part of my question, which is still based on what I've seen on Arch and Debian: there are a lot of users created by default (FTP, HTTP, etc.). Is there any use to them or do they only exist for historical reasons?

I'm thinking about removing them but don't want to break anything that could use it, but I have never seen anything doing so, and have no idea what could. Same goes for the default groups (tty, mem, etc.) that I've never seen any user belong to.

Solution 1

Per-user groups

I too don't see a lot of utility in per-user groups. The main use case is if a user wanted to allow "friends" access to their files, they can have the friend user added to their group. Few systems I've encountered actually use it this way.

When USERGROUPS_ENAB in /etc/login.defs is set to "no", useradd adds all the created users to the group defined in /etc/default/useradd by the GROUP field. On most of distributions, this is set to the GID 100 which usually corresponds to the users group. This does allow you to have a more generic management of users. Then, if you need finer control, you can manually add these groups and add users to them that makes sense.

Default created groups

Most of them came about from historic reasons, but many still have valid uses today :

• disk is the group that owns most disk drive devices
• lp owns parallel port (and sometimes is configured for admin rights on cups)
• uucp often owns serial ports (including USB serial ports)
• cdrom is required for mounting privileges on a cd drive
• Some systems use wheel for sudo rights; some not
• etc.

Other groups are used by background scripts. For example, man generates temp files and such when it's run; its process uses the man group for some of those files and generally cleans up after itself.

---

According to the Linux Standard Base Core Specification though, only 3 users that are root, bin and daemon are absolutely mandatory. The rationale behind the other groups is :

The purpose of specifying optional users and groups is to reduce the potential for name conflicts between applications and distributions.

So it looks as it is better to keep these groups in place. It's theorically possible to remove them without breakage, although for some, "mysterious" things may start to not work right (eg, some man pages not rendering if you kill that group, etc). It doesn't do any harm to leave them there, and it's generally assumed that all Linux systems will have them.

Solution 2

Question 1: Reasoning for Same User and Group

Hello, I'm ecyoung and you're horgix. We go to work everyday and login to the same Linux Server as programmers. One day, not long ago, our system admin decided to make user creation and maintainance easier on himself, so he turned off the USERGROUPS_ENAB option and put all the existing users in the new users group.

---

This did make user creation easier but not maintainance you see because all users can access all the other users files. In a corporate setting this is a big no no due to things like Sarbanes Oxley and Segregation of Duties. If I create File A, the Group Bit is set to the Users Group, which means that All users can at least read File A. If the sys admin is lazy, then in some cases all users can RW file A. This Defeats Sarbanes Oxley and SoD because separate departments should not be able to read much less write any other persons document.

---

With User/Group enabled if I create a document as ecyoung then only I have rwx rights to it. Since no one else is in my group, when they open my document they see a blank page with a warning. This enforces Sarbanes-Oxley and SoD. If I invite other users, those users are allowed rw access, and by doing so I know that what they see won't come back to bite me or them. As others have said, if at home, that separation may not be important to you. If you determine that, then you can safely turn the option off and all users will be added to a users group with a GID of 100. See Question 2 below.

Hypothetical:
You work in IT and Louis works in Payroll. Louis keeps the Tax and payroll sheet in her home directory, but you are both in the users group, so you open her home directory because its marked +r for users and find her spreadsheet. You find your salary amount listed, along with Joe's and Fred's. Do you think Joe and Fred would like you knowing their salary??

---

Question 2: Group IDs 0 through 500

Group IDs and conversely User IDs 0 - 500 are reserved for system accounts and device access. See the Pre-Configured system groups table for the list of Standard Accounts. Please do not remove these accounts by hand. For example if you want to remove the user ftp, remove the ftp daemon with your package management system. Doing so will also remove the system account. System Services include but are not limited to:

• The CUPS Printing Service
• The MySQL Server Daemon
• The FTP Server Daemon
• The Apace Web Server
• The X Server Socket for Remote Connections
• The ALSA Sound System Daemon
• The DBUS Service

There are others, so if other readers want to add or remove from the Service list above, please do so.

Solution 3

If we all share a default group, like in the old days, then we need to set our umask to 077 to block the group. If the default is me, then I can set the umask to 027, now if I set a directory or file to a shared group, this group can read. I don't have to mess about with modes as well.

This is just one example, but in general it is a way to disable groups, until you need them, in a way that makes them easier to turn on and manage.

Solution 4

Per-user groups lets you have both "privacy in your home directory" as well as "easy collaboration in shared folders". Without per-user groups, you can have either but not both. Details follow:

Unix is a multi-user system, whether it is a company file server or a pc with 2 users. "Privacy in your home directory" can be realized several ways:

Set "umask 077" so files are created with rw for you and no permissions for others. Alternatively, 027 or 022 so some or all may read but not write your files. The obvious disadvantage is that you can't collaborate in a shared folder because the others can't work on files you create there due to strict permissions. You may change permissions on such files, but that is "too much work" and often forgotten.

To collaborate, you want something like "umask 7" so both you and the owning group can read & write files you create. This is great for shared folders and groups consisting of all the people who need shared access. But you loose the privacy in your home folder!

The per-user group is the solution! You use umask 7, so all files you make gets "rw for you, and rw for the group". Files in your home directory gets created with your personal group as "owning group", so nobody else can access those files despite the "group rw" permission. Because nobody but you is in that particular group.

You can still collaborate in shared folders. Files in the shared folder gets "rw" for the owning group, and the sysadmin set up the shared folder so that a shared group (called collaborators) will be group owner for files there. This is done by creating this collaborators group, with all the collaborating users as members. Then, the admin sets group ownership of the shared folder to "collaborators" and set the SETGID permission for the shared folder. With SETGID on, anything created in the shared folder will get the same group owner as the shared folder - i.e. the "collaborators" group. And with umask 7 (or alternatively 2), people in this group will all have read+write access and so be able to collaborate. They will not have to change permissions away from default for the shared files - and they will still have privacy in their home folders thanks to the per-user groups used there.

View more solutions

Comments

[muru]

Nice hypothetical, but a fail. 1. Default permissions are usually masked 022, which means others have read access anyway. 2. The sysad is not only lazy, but incompetent, since he should have created groups according to the department and assigned the correct group during account creation, instead of assigning all to some group. The USERGROUPS_ENAB should remain turned off then. Disabling USERGROUPS_ENAB != putting all users in the same group.

[Jackie Choi]

@ECarterYound for the first part : I see what you mean about access protection, and correct me if I'm wrong but having all users in a users group should not be a problem with proper rights management on groups, that is not giving strictly the same rights to the group than the owner. So the only good point of having USERGROUPS_ENAB turned on is to have an easier maintainance since it allows you to keep default rights when creating files and directories while still having restricted access for other users ?

[eyoung100]

That would be correct, but a lot of people don't manage Groups correctly if they are home users. I can't verify this for sure, but I believe the maintainers created the option in order to shore up the permissions management.

[Jackie Choi]

Where can I find more about man generating temp files ? With an opened man page, ps aux | grep man doesn't show me any process running under the man group, and a find -group man / doesn't show me anything neither. Tried with man 2.6.7.1 on a standard Archlinux installation.