/etc/group

/etc/group stores local group records. It maps group names to numeric GIDs and lists explicit members, supporting access control shared by several accounts.

Local Groups versus Resolved Groups

The file is only one possible group source. NSS can resolve groups from local files, directory services, or other configured databases. Display the local records with:

$ cat /etc/group

Query the resolved group database with getent:

$ getent group
$ getent group developers

Group lists can disclose internal account and role names, so review output before sharing it.

Reading the Four Fields

A local record has four colon-separated fields:

developers:x:1500:alice,bob

1. Group name: developers.
2. Password field: Commonly x, *, or another placeholder; protected group-password data can be stored in /etc/gshadow.
3. GID: The numeric group identity, 1500 here.
4. Member list: Comma-separated explicit member names, alice and bob here.

Group passwords are a legacy feature used by tools such as newgrp in some configurations. They are not the normal mechanism for granting sudo authorization and should not be introduced through manual field edits.

Accounting for Primary Group Membership

The member list in /etc/group does not normally repeat users whose passwd record names that GID as their primary group. A user can therefore be a member even when their name is absent from field 4.

For example, if Alice's passwd record has primary GID 1500, she belongs to developers even if the local group record ends with an empty member field:

developers:x:1500:

This is why parsing field 4 alone produces an incomplete membership view.

Inspecting a User's Groups

Use id USER or groups USER for a resolved account view:

$ id alice
$ groups alice

For the current process, plain id reports the groups actually present in its credentials. A newly configured supplementary membership usually does not appear in an already running login session; start a new authenticated session or use a deliberately configured mechanism such as newgrp when appropriate.

Changing Local Groups Safely

Use tools such as groupadd, groupmod, groupdel, gpasswd, and usermod rather than editing records with a general-purpose editor. Be especially careful with:

• usermod -aG GROUP USER, which appends supplementary membership.
• usermod -G ..., which replaces the supplementary group list when -a is omitted.

If manual local database repair is unavoidable, use vigr for locking and grpck for validation. Keep a recovery path before remote identity changes.

To practice local group management in a controlled environment, try these hands-on labs:

1. Manage Linux User Accounts with useradd, usermod, and userdel - Practice the complete lifecycle of user administration, from creating and securing new accounts to modifying and deleting them.
2. Manage Linux Groups with groupadd, usermod, and groupdel - Gain hands-on experience with core command-line utilities for group administration, including groupadd, usermod, and groupdel.
3. Add New User and Group - Simulate adding new team members to a server environment by creating new user accounts, setting up custom groups, and managing group memberships.

Summary

You can now interpret local group records and resolve complete membership more accurately.

1. Query configured group sources with getent group.
2. Read the four colon-separated group fields.
3. Locate the numeric GID and explicit member list.
4. Include primary membership from passwd records.
5. Inspect active credentials before relying on a changed membership.