GeezerVison

The effective GID (egid) of a process is used for file access checks and may also affect file creation, depending on the semantics of the specific kernel implementation in use and possibly the mount options used. According to BSD Unix semantics, the group ownership given to a newly created file is unconditionally inherited from the group ownership of the directory in which it is created. According to AT&T UNIX System V semantics (also adopted by Linux variants), a newly created file is normally given the group ownership specified by the egid of the process that creates the file. Most filesystems implement a method to select whether BSD or AT&T semantics should be used regarding group ownership of a newly created file; BSD semantics are selected for specific directories when the S_ISGID (s-gid) permission is set.^[2]

The real GID (rgid) identify the real group owner of the process.

The saved group ID is used when a program running with elevated privileges needs to do some unprivileged work temporarily; changing egid from a privileged value (typically 0) to some unprivileged value (anything other than the privileged value) causes the privileged value to be stored in sgid. Later, a program's egid can be set back to the value stored in sgid, so that elevated privileges can be restored; an unprivileged process may set its egid to one of only three values: the value of rgid, the value of sgid, or the value of egid.

Every user must be a member of at least one group, the primary group, which is identified by the numeric GID of the user's entry in the passwd database, which can be viewed with the command getent passwd (usually stored in /etc/passwd or LDAP). This group is referred to as the primary group ID. A user may be listed as member of additional groups in the relevant entries in the group database, which can be viewed with getent group (usually stored in /etc/group or LDAP); the IDs of these groups are referred to as supplementary group IDs.

Originally, a signed 16-bit integer was used. Since the sign was not necessary – negative numbers do not make valid group IDs – an unsigned integer is now used instead, allowing group IDs between 0 and 65,535. Modern operating systems usually use unsigned 32-bit integers, which allow for group IDs between 0 and 4,294,967,295.

Many Linux systems reserve the GID number range 0 to 99 for statically allocated groups, and either 100−499 or 100−999 for groups dynamically allocated by the system in post-installation scripts. These ranges are often specified in /etc/login.defs, for useradd, groupadd and similar tools.

On FreeBSD, porters who need a GID for their package can pick a free one from the range 50 to 999 and then register this static allocation in ports/GIDs.^[3]

• 0: The superuser normally has a GID of zero (0).
• −1: The value (gid_t) -1 is reserved by POSIX to identify an omitted argument.^[4]
• 65,534: The Linux kernel defaults to 2¹⁶−2 = 65,534 (which many Linux distributions map to the group name "nogroup") when a 32-bit GID does not fit into the return value of a 16-bit system call.^[5] The value is also returned by idmapd if a group name in an incoming NFSv4 packet does not match any known group on the system.