Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I've noticed that on a number of linux distributions that whenever a new user is created, it is assigned to a primary group of its own name.

eg. If i create a user called "testuser", by default it is assigned to the "testuser" primary group.

This causes all users to have their own unique primary groups. All these groups would also only ever have 1 user as it wouldn't really make sense to add other users to these groups. This is somewhat counter inituitive as "group" generally means "more than 1".

These user primary groups are also generally useless when attempting to assign permissions to files/folders.

Is there any reason this is the default behaviour on distros ? And any use cases where this behaviour is actually useful ? Why not assign all new users to a "users" primary group ?

share|improve this question
    
This might help. –  devnull Mar 29 at 12:05
    
I was wondering why this seemingly useless behaviour is the default and what are the actual uses for it. Thanks for the link anyway ! –  peonicles Mar 29 at 12:09
2  
Security seems to be one reason. –  devnull Mar 29 at 12:12
    
hmm could you give a more concrete example for security ? I'd think that user home permissions could be set to 700, and the default umask could be set to 077 ... –  peonicles Mar 29 at 12:21

2 Answers 2

up vote 4 down vote accepted

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.

share|improve this answer

It was customary to add all users to group users, but that makes sharing files in a controlled way awkward (open up group permissions, everybody has access). As today a process can belong to a lot of groups at the time, just close access by giving each user her own group, and share files by adding explicit groups for this. Or (if available) use ACLs.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.