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
.
Your issue may be related with the --manage-gids
option of rpc.mountd
enabled by default in debian (see /etc/default/nfs-kernel-server
).
From the man page:
-g or --manage-gids
Accept requests from the kernel to map user id numbers into lists of group id numbers for use in access control. An NFS request will normally (except when using Kerberos or other cryptographic authentication) contains a user-id and a list of group-ids. Due to a limitation in the NFS protocol, at most 16 groups ids can be listed. If you use the -g flag, then the list of group ids received from the client will be replaced by a list of group ids determined by an appropriate lookup on the server. Note that the 'primary' group id is not affected so a newgroup command on the client will still be effective. This function requires a Linux Kernel with version at least 2.6.21.
So if you don't hit the "16 groups" limit, you may try to disable this option on your server.
Best Answer
From Unix Groups:
Imagine there is no primary group assigned to my User and I'm in 10 secondary groups. I create a new file... what group this file belongs to? which one of these 10? primary group tackles this issue and defines which group the file belongs to by default. You don't want the files you are creating in your home directory to be owned by development group so anyone on that group can do the stuff allowed to do with them as the group.
No! only permissions defined by group part. Of course it is possible to do it. Using
umask
for example.