I know Linux has some limitations for the number of groups a user can be part of. I found out that it is 16 groups for each user, and depends on the Linux kernel. However, is there any restriction for the number of users that can be part of a single group? For example, if I create a "book" group in Debian 10, how many users I can add to this group –or– how many users can I share this group between at the same time?
Linux Debian – Maximum Number of Users in a Group
debiangrouplinux-kernelusers
Related Solutions
The usermod
command will allow you to change a user's primary group, supplementary group or a number of other attributes. The -g
switch controls the primary group.
For your other questions...
If you specify a group,
groupname
, that does not exist during theuseradd
stage, you will receive an error - useradd: unknown group groupnameThe
groupadd
command creates new groups.The group will remain if you remove all users contained within. You don't necessarily have to remove the empty group.
Create the
hilbert
group viagroupadd hilbert
. Then move David's primary group usingusermod -g hilbert hilbert
. (Please note that the firsthilbert
is the group name and the secondhilbert
is the username. This is important in cases, where you are moving a user to a group with a different name)
You may be complicating things a bit here, though. In many Linux distributions, a simple useradd hilbert
will create the user hilbert
and a group of the same name as the primary. I would add supplementary groups specified together using the -G
switch.
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
.
Best Answer
The 16-group limit isn’t related to the kernel, but to NFS. On Linux, since kernel 2.6.3, processes can have up to 65,536 supplementary groups.
Going in the other direction, there isn’t any limit on the number of users in a group set by the kernel or the C library, apart from the limit imposed by the maximum group identifier (so 232 different groups in the kernel, where gids are represented by unsigned
int
s). The library functions and data structures used to access groups support an unlimited number of users. There can be limits set by the underlying data storage (e.g. in LDAP), but I’m not aware of any (other than disk storage, and perhaps reduced performance with large numbers of users) in/etc/passwd
//etc/group
.In both cases, applications can have bugs when faced with users with lots of groups, or groups with lots of users. See this example in LXC, which meant that, when too many users were part of the same group, no rootless container could get network access (thanks to A.B for the reminder and pointer).