Back to Home

Linux users UID GID groups management

Article breaks down user identification by UID/GID in Linux, access model, files /etc/passwd shadow group. Commands id getent useradd vipw shown for diagnostics and account management.

Linux User Management: UID groups useradd
Advertisement 728x90

Linux User and Group Management: UID, GID, and Account Control

The Linux kernel works with numeric identifiers—UIDs and GIDs. A username is just a human-readable alias stored in /etc/passwd. Processes and files are tied to these numbers, so changing a username without preserving the original UID will result in loss of access to resources.

Check current user:

id
# uid=1001(deployer) gid=1001(deployer) groups=1001(deployer),27(sudo),998(docker)

id -u  # Only UID
whoami # Only username
getent passwd deployer

getent queries NSS modules—including LDAP—unlike direct file reading.

Google AdInline article slot

Access Model and Ownership

Each inode stores an owner (UID) and group (GID). The kernel checks permissions in this order: process UID/GID → owner? → group? → others. The first match determines access.

Example:

ls -la /var/log/nginx/
# -rw-r----- 1 www-data adm 187234 Mar 26 10:41 access.log

Owner is www-data, group is adm. A process running as www-data gets owner-level access, ignoring group membership.

Google AdInline article slot

UID ranges:

  • 0: root
  • 1–999: system accounts (daemons, no login)
  • 1000+: regular users
  • 65534: nobody

Configured in /etc/login.defs.

System users use /usr/sbin/nologin or /bin/false to prevent login:

Google AdInline article slot
awk -F: '$3 < 1000 && $3 > 0 {print $1, $3, $7}' /etc/passwd

Groups: Shared Access

Primary group (GID in /etc/passwd) applies to new files. Supplementary groups are listed in /etc/group.

Check membership:

groups  # Current groups
getent group docker  # Members
docker:x:998:deployer,ci

Groups simplify access control: add a user to the docker group to grant socket access without sudo.

Configuration Files

/etc/passwd (readable by all):

deployer:x:1001:1001:Deploy Bot,,:/home/deployer:/bin/bash

Fields: username | password placeholder (x) | UID | GID | GECOS | home directory | shell.

/etc/shadow (root-only): contains SHA-512 or yescrypt hashes, password expiration settings.

deployer:$6$rounds=5000$xPwF...$kE9...hash...:19800:0:99999:7:::

/etc/group:

docker:x:998:deployer,ci-bot

Safe editing commands:

vipw    # Edit passwd with lock
vigr    # Edit group
pwck    # Validate configuration

Creating and Configuring Users

Use useradd with key options:

| Option | Description |

|--------|-------------|

| -m | Create home directory |

| -s | Set default shell |

| -G | Add supplementary groups |

| -r | System account |

| -u | Specify UID |

Examples:

useradd -m -s /bin/bash -G sudo,docker ivan
useradd -r -s /usr/sbin/nologin ci-bot

passwd ivan  # Set password
chpasswd <<< 'ivan:secret'
passwd -e ivan  # Force password change on next login

useradd -m copies from /etc/skel and sets ownership on the home directory.

umask subtracts from 0666 (files) or 0777 (directories). Default: 0022.

Environment and Templates

/etc/skel holds templates for new user homes: .bashrc, .profile.

Global settings:

  • /etc/default/useradd: defaults for useradd
  • /etc/profile.d/*.sh: environment scripts for logins
  • /etc/login.defs: umask, UID range settings

Key Takeaways:

  • UID controls access, not username.
  • Use getent instead of cat /etc/passwd for NSS-aware lookups.
  • Groups are the primary mechanism for delegating privileges.
  • Always edit config files via vipw or vigr.
  • System accounts should have /usr/sbin/nologin or /bin/false and UID < 1000.

— Editorial Team

Advertisement 728x90

Read Next