A security-focused guide to the id command — covering effective privilege verification, group membership auditing, and how to use id during post-compromise triage to detect privilege manipulation.
What is the id command?
The id command prints the real and effective user ID (UID), group ID (GID), and supplementary group memberships of the current or specified user. Despite its simplicity, id is a critical security verification tool. During post-compromise triage, it confirms what privilege a process or interactive session actually has at runtime — which may differ from what was expected. An attacker who adds a service account silently to the sudo or docker group has escalated their potential privilege without changing the account’s primary group. The id command exposes this immediately. It is the fastest way to answer the question: exactly what can this identity do right now?
Syntax
id
id username
id -u
id -g
id -G
id -unid with no arguments prints the full identity of the current user. id username prints identity for another account. The -u flag returns only the numeric UID, -g returns the primary GID, -G returns all group IDs, and -n combined with any of these returns names instead of numbers.
Key Options and Flags
| Flag / Parameter | Description | Security Note |
|---|---|---|
(no args) | Print full identity: uid, gid, and all supplementary groups | The most useful form — shows all group memberships that could be exploited for privilege escalation |
username | Print identity of the specified user account | Use during audits to check if service accounts have unexpected group memberships |
-u | Print only the numeric effective user ID | If this returns 0, the current process is running as root — regardless of the username displayed |
-g | Print only the numeric effective group ID | — |
-G | Print all numeric supplementary group IDs | Key for detecting hidden group membership that grants additional capabilities |
-n | Print names instead of numeric IDs (combine with -u, -g, or -G) | — |
Common Use Cases
Verify Effective Privilege During Post-Compromise Triage
When investigating a potentially compromised account, id reveals the effective privilege at the current moment. A service account that was supposed to be unprivileged but shows membership in sudo, docker, adm, disk, or shadow groups has elevated capabilities. The docker group is particularly dangerous — membership provides a trivial root escalation path via container volume mounts.
id www-data
id mysql
id nginx
id deploy-userAudit All Human Accounts for Unexpected Group Membership
A regular group membership audit compares current group assignments against the expected baseline. Any service account in sudo, any human account in docker without documented justification, or any new account in shadow or disk groups warrants investigation. Automate this check as part of routine monitoring.
awk -F: '$3 >= 1000 {print $1}' /etc/passwd | while read user; do
groups=$(id -Gn "$user" 2>/dev/null)
echo "$user: $groups"
done | grep -E '(sudo|wheel|docker|disk|shadow|adm)'Confirm Service Account Does Not Have Sudo Group Membership
Service accounts added to the sudo or wheel group can run arbitrary root commands. This is a persistence mechanism used by attackers after initial compromise. Verify that all service accounts have only their expected group memberships and have no path to privilege escalation via group membership.
id www-data | grep -E '(sudo|wheel|docker)' && echo 'WARNING: unexpected privilege' || echo 'OK'
id mysql | grep -E '(sudo|wheel|docker)' && echo 'WARNING: unexpected privilege' || echo 'OK'Security Relevance: Group Membership as a Privilege Escalation Path
Linux group membership is a frequently overlooked privilege escalation vector. The sudo and wheel groups are obvious targets, but several other groups provide significant capabilities without requiring root: docker (mount any filesystem into a container and read it as root), disk (raw access to block devices), shadow (read /etc/shadow and crack password hashes offline), adm (read system logs including auth.log), lxd (equivalent to docker for privilege escalation via container filesystem mounts). Attackers who achieve initial access as a low-privilege user will immediately run id to enumerate available group-based escalation paths. Your audit process should identify these paths first — before an attacker does. The id command takes one second and answers the critical question: does this account have any non-obvious capabilities that could be abused?
- docker group membership is equivalent to root access — any user in the docker group can trivially escalate to root
- disk group membership allows reading raw block devices — use it to bypass filesystem-level permissions and read any data
- shadow group membership allows reading /etc/shadow — enables offline password cracking of all accounts
- adm group membership allows reading /var/log/auth.log — enables surveillance of all authentication events
- New accounts created by attackers for persistence often have UIDs > 1000 and are added to multiple privileged groups
Practical Examples
Check if the current session has unexpected root access
id -u
id -un
[ $(id -u) -eq 0 ] && echo 'WARNING: Running as root' || echo "Running as: $(id -un)"The numeric UID of 0 means root regardless of what username is displayed. In a compromised environment, an attacker may rename or alter accounts. Always verify effective UID numerically, not by username.
List all members of the sudo group on the system
getent group sudo
getent group wheel
grep -E '^sudo:|^wheel:' /etc/groupShows all accounts with sudo group membership. Compare against an expected list of administrators. Any unexpected account in this group is a critical security finding requiring immediate investigation.
Full privilege audit of all accounts with UID >= 1000
awk -F: '$3 >= 1000 {print $1}' /etc/passwd | while read user; do
echo "=== $user ==="
id "$user"
donePrints the complete identity and group membership of every human account on the system. Run this at the start of any security audit or incident response investigation to establish a complete privilege map of all accounts.
Troubleshooting Common Issues
Problem: id shows correct groups but user cannot perform expected group-based actions
Solution: The user may not have refreshed their login session after group changes. id reflects the identity as stored in the kernel for the current session. Group membership changes take effect only after the user logs out and back in, or starts a new session with newgrp groupname.
Problem: id username returns different groups than id (no args) for the same user
Solution: The no-argument form shows the current session’s effective identity (which may include supplementary groups loaded at login). The username form reads from /etc/group and /etc/passwd. These differ if group changes were made after the user logged in, or if LDAP/SSSD caching is involved.
Problem: Service account appears in a group in /etc/group but id shows a different GID
Solution: There may be a discrepancy between /etc/group and the NSS source in use. Check /etc/nsswitch.conf for the group entry. If LDAP or SSSD is configured, group membership may come from the directory service, not the local file.
Summary
The id command is the fastest way to enumerate an account’s effective privilege on a Linux system. In incident response, it answers the critical question of what a compromised account can actually do. In routine hardening, it confirms that service accounts have not been silently granted additional group memberships that provide escalation paths. Run it as the first command when investigating any account — it takes under a second and provides immediate, accurate privilege intelligence.
- Run
idon every account during incident response to enumerate group-based escalation paths docker,disk,shadow, andsudogroup membership is effectively a root escalation path — audit regularly- Numeric UID 0 means root regardless of displayed username — always verify with
id -u, not justwhoami
Related Commands
sudo privilege auditing • passwd for account locking • chown for file ownership management • last for login history forensics
Do You Know the Actual Privilege of Every Account on Your Server?
INTRAM performs group membership and privilege audits as part of every managed server engagement. We identify escalation paths before attackers do and enforce least-privilege across all accounts.
Request a Privilege Audit