Overview
Not every account belongs to a person. Service accounts (system users) exist so that background services run with their own limited identity rather than as root or as a human user. This lesson explains service users and why they are a key security practice.
Learning objectives
- Define a service (system) account.
- Explain why services run under dedicated accounts.
- Recognize service accounts when enumerating a system.
Core concept
A service account is a non-human user that a background service or daemon runs as. These accounts typically have:
- A low UID (commonly below 1000, in the system range).
- No login shell (e.g.
/usr/sbin/nologinor/bin/false), so no one can log in as them interactively. - Minimal privileges, scoped to only what the service needs.
Examples include accounts like www-data (web server), mysql/postgres (databases), and sshd.
How it works
Running each service under its own dedicated, unprivileged account applies least privilege at the service level: if a service is compromised, the attacker gains only that account's limited access — not root, and not a human user's data. The nologin shell prevents these accounts from being used for interactive login, reducing their usefulness to an attacker. Administrators (and packages) create such accounts precisely so a flaw in one service does not endanger the whole system.
Practical example
A web server process typically runs as www-data, whose /etc/passwd entry might look like:
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
UID 33 (system range), home /var/www, and shell /usr/sbin/nologin — meaning the web service runs with a confined identity that cannot be logged into interactively. If the web app were exploited, the attacker would initially be limited to www-data's access, not root.
Cybersecurity relevance
Service accounts embody least privilege and compromise containment. A key finding in assessments is a service running as root unnecessarily, since exploiting it would then hand over full control — running as a confined service user greatly limits the blast radius. During enumeration, distinguishing service accounts (low UID, nologin) from human accounts helps map how a system is structured and where privilege escalation from a service account might be attempted.
Common mistakes
- Running services as root when a confined service account would suffice, maximizing the impact of a compromise.
- Giving service accounts a login shell, needlessly increasing their usefulness to an attacker.
- Mistaking service accounts for human users during enumeration.
Key takeaways
- Service (system) accounts let background services run under dedicated, unprivileged identities, typically with low UIDs and no login shell.
- Running each service under its own confined account applies least privilege and contains the impact of a compromise.
- A service running as root is a common, serious finding; recognizing service accounts (low UID, nologin) aids enumeration and privilege-escalation analysis.
Check your understanding
- Why do service accounts typically have a shell like
/usr/sbin/nologin? - What is the security benefit of running a service under its own dedicated account rather than as root?