id

What it does

id prints identity information for the current user or a specified user: their numeric user ID (UID) and username, primary group ID (GID) and name, and every supplementary group they belong to. Run with no arguments it reports on the caller; given a username it reports on that user instead. It's the definitive tool for checking exactly which permissions a user's group memberships grant them.

Beginner examples

• id — show full identity info (UID, GID, and groups) for the current user
• id shivam — show the same info for the user shivam
• id -u — print just the numeric UID
• id -un — print just the username (equivalent to whoami in most cases)

id

Advanced examples

• List every group a user belongs to by name: id -Gn shivam
• Check if the current user is in the docker or sudo group before running a privileged command: id -nG | tr ' ' '\n' | grep -qx docker && echo "in docker group"
• Compare real vs. effective IDs inside a setuid context: plain id shows both uid= and euid= when they differ.
• Numerically gate a script for root only: [ "$(id -u)" -eq 0 ] || { echo "run as root"; exit 1; }
• Confirm a newly created user's group assignments right after useradd: id newuser

[ "$(id -u)" -eq 0 ] || { echo "This script must run as root" >&2; exit 1; }

Common mistakes

• Using id -u for a root check but comparing it as a string instead of a number, e.g. [ "$(id -u)" = "0" ] works, but forgetting quotes or comparison operators is a frequent source of script bugs.
• Assuming id's groups= output only shows the primary group — it actually lists the primary group plus every supplementary group the user belongs to.
• Confusing "real" and "effective" IDs — they only diverge in specific contexts like setuid binaries or explicit privilege drops; in a normal login shell they're identical.
• Forgetting group membership changes (via usermod -aG) don't apply to already-open sessions — the user typically needs to log out and back in (or start a new shell) for id to reflect the new group.

Tips

• id -nG (name, all Groups) is the fastest way to answer "what groups am I actually in?" without cross-referencing /etc/group manually.
• Combine id with groups (a related, simpler command) when you just want a quick space-separated group list without UID/GID numbers.
• Scripts that need to confirm docker/sudo/wheel access commonly grep the output of id -nG for the specific group name.

Best practices

• Use id -u (numeric) rather than whoami/id -un (name-based) for root/permission checks in scripts — comparing an integer to 0 is unambiguous.
• After adding a user to a group with usermod -aG, verify with id <username> in a fresh shell/session, not the same one, since group membership is loaded at login.
• When debugging "permission denied" issues, run id first to confirm the user actually has the expected group membership before digging into file permissions.

Real-world use cases

• Verifying a user was correctly added to the docker, sudo, or wheel group after an administrative change.
• Gating installation or deployment scripts so they refuse to run unless invoked as root (id -u equals 0).
• Debugging permission errors by confirming the actual UID/GID/groups a process or session is running under.
• Auditing which supplementary groups a service account has been granted, as part of a security review.

Common interview questions

• What's the difference between id -u and whoami? id -u prints the numeric user ID; whoami (and id -un) prints the corresponding username — both refer to the effective user.
• How would you check all groups a user belongs to? id -Gn <username> prints the names of every group, including supplementary ones, that the user is a member of.
• When would id's uid= and euid= fields differ? When a process's real user ID and effective user ID diverge, such as when running a setuid binary or after a program has explicitly dropped/elevated privileges.