4. Users, Groups, Permissions and Identity

Introduction and Context

Linux is a multi-user operating system. Its security model assumes that many people, services, applications, and automated processes may use the same machine while requiring different levels of access. Administration therefore involves more than creating usernames. It requires the deliberate design of identities, authentication mechanisms, authorization rules, privilege boundaries, and evidence of access.

In DevOps environments, these concerns extend across virtual machines, containers, cloud instances, configuration-management systems, CI/CD runners, and production platforms. A poorly designed account or permission can expose source code, credentials, customer data, or infrastructure controls. Conversely, excessive restrictions can prevent reliable automation and encourage unsafe workarounds. The administrator must balance availability, operational efficiency, security, and auditability.

This chapter examines Linux users, groups, profiles, permissions, sudo, Pluggable Authentication Modules (PAM), access control lists (ACLs), capabilities, quotas, and SSH identities. These mechanisms are best understood as parts of one access-governance system based on least privilege, separation of duties, and accountability.

Learning Objectives

After studying this chapter, students should be able to:

• explain Linux identity and authorization concepts;
• create, modify, disable, and audit users and groups;
• interpret traditional permissions, ACLs, and capabilities;
• design controlled administrative access using sudo and PAM;
• distinguish password-based authentication from SSH key identity;
• configure profiles, quotas, and service accounts appropriately;
• diagnose common access failures without weakening security;
• apply least privilege, separation of duties, and auditability in operational scenarios.

Identity as the Foundation of Access Control

A Linux identity is represented primarily by a numeric user identifier (UID) and group identifiers (GIDs). Usernames and group names are human-readable mappings stored locally or obtained from identity services such as LDAP, Active Directory integration, or centralized cloud directories. The kernel ultimately evaluates numeric IDs, not the text of a username.

The superuser, conventionally named `root`, has UID 0 and possesses extensive authority. Root is not simply an ordinary user with more permissions; many restrictions do not apply to it. For this reason, direct root login and routine work as root are discouraged. Administrative actions should normally be performed through controlled privilege elevation, especially `sudo`, so that commands can be restricted and recorded.

Linux accounts commonly fall into three categories. Human accounts represent people and normally have interactive shells and home directories. Service accounts represent applications or daemons and should normally have no interactive login. System accounts support operating-system functions and often use reserved UID ranges. Treating service accounts as human accounts creates unnecessary attack paths, particularly when they have passwords, writable home directories, or broad group membership.

Important account databases include `/etc/passwd`, `/etc/shadow`, `/etc/group`, and `/etc/gshadow`. The first contains basic account attributes but not password hashes. Password hashes and password-aging data are kept in `/etc/shadow`, which is readable only by privileged processes or members of an appropriately restricted group. The Name Service Switch configuration in `/etc/nsswitch.conf` determines where identity information is obtained. Thus, an account may appear local to a command while actually being resolved through a directory service.

Useful inspection commands include:

```bash

id alice

getent passwd alice

getent group developers

who

last

```

`id` displays the effective UID, primary group, and supplementary groups. `getent` is preferable to reading only local files when centralized identity services may be present.

Users, Groups, and the Administrative Lifecycle

Account administration should follow a lifecycle: request and approval, creation, role assignment, authentication configuration, periodic review, suspension or modification, and final removal or archival. The technical command is only one stage of this process. In an enterprise, ownership, approval, expiry, and evidence are equally important.

A typical local account may be created with:

```bash

sudo useradd -m -s /bin/bash -c "Build Operator" buildop

sudo passwd buildop

sudo usermod -aG developers buildop

```

The `-m` option creates a home directory, while `-s` selects the login shell. The `-aG` combination is important: omitting `-a` when modifying supplementary groups can replace the user’s existing supplementary-group membership. Account expiry and password aging can be inspected or configured with `chage`:

```bash

sudo chage -l buildop

sudo chage -M 90 -W 14 buildop

sudo usermod -L buildop

sudo usermod -U buildop

```

Locking an account is not identical to deleting it. A locked password may prevent password authentication while leaving other authentication paths available, such as SSH keys. When an employee leaves, administrators should disable all relevant paths, remove authorized keys, revoke tokens, review ownership of files and jobs, and preserve records according to policy.

Groups express functional or project membership. A primary group is associated with a user’s new files by default; supplementary groups provide additional access. Group-based authorization is generally more maintainable than assigning permissions to individual users. However, group membership is itself privileged information: membership in groups such as `sudo`, `adm`, `docker`, or storage-administration groups may provide powerful access.

File Permissions and the Principle of Least Privilege

Traditional Unix permissions divide access into three classes: owner, group, and others. Each class can have read (`r`), write (`w`), and execute (`x`) permission. For regular files, read permits content access, write permits modification, and execute permits execution. For directories, read permits listing names, write permits creating, deleting, or renaming directory entries, and execute permits traversal and access to known entries.

A mode such as `rwxr-x---` can be represented numerically as 750. The values are read = 4, write = 2, and execute = 1. Administrators use `chmod`, `chown`, and `chgrp` to manage these attributes:

```bash

chmod 640 report.csv

chown analyst:finance report.csv

chmod 750 /srv/finance

```

The permission of a path depends on every directory in the path. A user may have permission on a file but still be unable to reach it because traversal permission is missing on a parent directory. This is a frequent source of apparently contradictory access results.

The set-user-ID (setuid), set-group-ID (setgid), and sticky-bit mechanisms modify ordinary behavior. Setuid on an executable can cause it to run with the file owner’s effective UID; because this creates privilege-escalation risk, such files require careful inventory. Setgid on a directory causes new files to inherit the directory’s group, which is useful for collaborative workspaces. The sticky bit on a shared directory, such as `/tmp`, limits deletion of entries to their owners, the directory owner, or root.

Default permissions are influenced by the process umask. For example, a umask of `027` prevents group write and all permissions for others from newly created objects, subject to the application’s requested mode. Umask is a useful baseline but is not a substitute for reviewing existing permissions.

ACLs: More Precise Authorization

Traditional permissions provide one owner and one group. Access control lists extend this model by assigning permissions to named users and groups. They are valuable when a resource must be shared with a specific team without changing ownership or granting access to an entire existing group.

ACLs can be examined and changed with `getfacl` and `setfacl`:

```bash

setfacl -m u:auditor:r-- /srv/finance/report.csv

setfacl -m g:reviewers:r-x /srv/finance

getfacl /srv/finance/report.csv

```

An ACL contains a mask that limits the effective permissions of named users, named groups, and the owning group. Therefore, the displayed entry and the effective entry may differ. Default ACLs on directories can cause permissions to propagate to newly created files and directories:

```bash

setfacl -m d:g:reviewers:rx /srv/finance

```

ACLs improve precision but also increase complexity. They should be documented, periodically reviewed, and removed when no longer necessary. A permission audit that checks only `ls -l` can miss significant access granted through ACLs.

Sudo, Separation of Duties, and Controlled Privilege

`sudo` allows an authorized user to execute selected commands with another identity, normally root. Its policy is defined in `/etc/sudoers` and files under `/etc/sudoers.d`. Always validate changes with `visudo`, which checks syntax before installing the policy.

A restrictive policy might resemble:

```text

%release-engineers ALL=(root) /usr/bin/systemctl restart webapp, /usr/bin/journalctl -u webapp

```

This grants the group only specified commands. However, command restrictions require careful analysis. If an allowed command can invoke a shell, edit arbitrary files, or load plugins, the restriction may be illusory. Wildcards should be used cautiously, and command paths should be explicit.

Sudo supports identity and accountability features such as authentication timestamps, command logging, and I/O logging. Organizations may also use centralized logging or specialized privilege-management tools. The goal is not merely to make elevation possible, but to make it attributable and reviewable.

Separation of duties means that no single person should control every stage of a sensitive activity. For example, one team may develop a deployment, another may approve it, and a controlled automation account may execute it. This reduces the risk of fraud, error, and unauthorized change. Shared administrator accounts undermine separation of duties because actions cannot be reliably attributed to individuals.

PAM and the Authentication Stack

PAM is a framework that allows applications to use modular authentication and account-management policies. A PAM service configuration may contain modules for authentication, account validity, password changes, and session setup. Files commonly appear under `/etc/pam.d/`, while the exact modules differ across distributions.

PAM can enforce password quality, account lockout, multi-factor authentication, access schedules, session limits, and centralized identity policies. A conceptual authentication flow may include:

1. verifying a presented credential;

2. checking whether the account is permitted to log in;

3. applying password or credential-change rules;

4. establishing session resources and environment.

PAM configuration is powerful but hazardous. A syntax or ordering error can prevent all administrative logins. Administrators should maintain console or out-of-band recovery access, test changes in a non-production system, preserve backups, and understand the behavior of every module. Security controls must not be applied blindly; an account lockout policy, for example, can be abused for denial of service if not designed carefully.

Profiles, Shell Environments, and Identity Context

A user’s environment affects both usability and security. System-wide initialization files may include `/etc/profile` and files under `/etc/profile.d/`; user-specific files commonly include `~/.profile`, `~/.bash_profile`, and `~/.bashrc`, depending on the shell and whether the session is a login or interactive shell.

Profiles define variables such as `PATH`, aliases, locale settings, proxy configuration, and tool initialization. A secure `PATH` should not begin with the current directory, and scripts should use absolute paths for security-sensitive commands. Writable directories in a privileged user’s `PATH` can enable command hijacking. Administrators should distinguish interactive shell configuration from non-interactive automation, because a CI job may not read the same files as an SSH login.

The `HOME`, `USER`, `LOGNAME`, and `SHELL` variables describe session context but should not be trusted as proof of identity. Security decisions must rely on kernel credentials and authenticated session data rather than user-controlled environment variables.

SSH Identities and Remote Administration

SSH supports password authentication, public-key authentication, certificates, and other mechanisms. With public-key authentication, the client proves possession of a private key while the server stores the corresponding public key, commonly in `~/.ssh/authorized_keys`. The private key must remain secret and should be protected by a passphrase, preferably managed through an agent or approved secret-management system.

A key can be generated with:

```bash

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519

ssh-copy-id [email protected]

ssh [email protected]

```

The file `~/.ssh/authorized_keys` may include restrictions such as `from=`, `command=`, `no-agent-forwarding`, `no-port-forwarding`, and `no-pty`. These options are particularly valuable for automation keys. A deployment key that only runs a fixed deployment command is safer than a general interactive key.

SSH hardening commonly includes disabling direct root login, preferring key or certificate authentication, limiting allowed users or groups, protecting host keys, and monitoring login events. Host-key verification protects against impersonation; ignoring verification warnings defeats an important security mechanism. SSH agents also require care because forwarding an agent to an untrusted host can expose the ability to use loaded keys.

Capabilities and Quotas: Narrowing Privilege and Resource Use

Traditional root privilege is broad. Linux capabilities divide some privileged operations into distinct units, such as binding to low network ports, changing file ownership, or administering networking. Capabilities can be attached to executables or assigned to processes. For example, `CAP_NET_BIND_SERVICE` may allow a program to bind to ports below 1024 without running fully as root.

Capabilities support least privilege but are not automatically safe. A vulnerable program with a powerful capability may still compromise the system. Administrators should inspect file capabilities with `getcap`, minimize them, and include them in security reviews. In containerized environments, dropping unnecessary capabilities is a fundamental hardening practice.

Disk quotas limit user or group consumption of storage, usually by blocks and inodes. They protect system availability against accidental or malicious exhaustion. Quotas are especially relevant on shared servers, mail systems, build hosts, and multi-tenant platforms. A quota policy should distinguish warning thresholds from hard limits and should include monitoring, because a hard limit can interrupt legitimate workloads if capacity planning is poor.

Applied Case: Securing a Shared Deployment Host

Background

A software company operates a Linux host used by developers, release engineers, and a CI system. Developers need to read build artifacts, release engineers must restart a web service, and the CI system must publish approved releases. The original design uses a shared `deploy` account, password-based SSH, and a writable application directory.

Problem

An audit finds that actions cannot be attributed to individuals. Any user who obtains the shared password can access production. The CI account can modify service configuration, and developers can alter files that are executed by the web service.

Analysis

The weaknesses are failures of identity governance and privilege separation. A shared account removes individual accountability. Password authentication increases exposure to credential theft. The writable application directory creates a path from developer access to service compromise. Finally, the CI account has more authority than its publishing task requires.

Approach and Solution

The organization creates named accounts linked to centralized identity services and removes interactive use of the shared account. Developers are placed in a read-only artifact group. Release engineers receive a tightly scoped sudo rule permitting only the required service restart and status commands. CI receives a dedicated service account with a forced SSH command and a restricted key; it can write only to a staging location and invoke an approved deployment program.

The application directory is owned by a deployment account and is not writable by developers. A separate group and default ACL provide controlled read access to artifacts. Direct root SSH login is disabled, password authentication is removed after key-based access is verified, and sudo and SSH logs are forwarded to a central monitoring system. Account reviews and key rotation are scheduled quarterly.

Outcome

Individual administrative actions become attributable. The CI identity can perform its deployment function but cannot obtain a general shell or alter unrelated system files. Developers retain necessary visibility without receiving production modification rights. The design also provides evidence for audit and a clearer procedure for revoking access.

Learning Points

The case demonstrates that least privilege is not achieved by one command. It results from combining named identities, group design, file ownership, ACLs, restricted sudo, SSH controls, service-account limitations, monitoring, and lifecycle review.

Risks, Mistakes, and Governance Considerations

Common mistakes include granting `777` permissions to solve an access problem, adding users to powerful groups without analysis, using unrestricted `NOPASSWD: ALL`, storing private keys in repositories, editing sudoers with a normal editor, and assuming that locking a password disables every authentication method. Other errors include failing to review ACLs, leaving departed users’ files and scheduled jobs active, and placing writable directories before trusted directories in a privileged `PATH`.

Access governance should define ownership, approval authority, periodic recertification, emergency access, evidence retention, and revocation procedures. Privacy principles also matter: logs should support accountability without collecting unnecessary personal information. Administrators must protect authentication data, respect organizational policy, and ensure that monitoring is proportionate and legally permitted.

Automation improves consistency. Configuration-management tools can declare users, groups, sudo policies, SSH authorized keys, file modes, and quotas as code. Compliance scanners can detect drift, while audit frameworks can record privileged commands and authentication events. Automation must itself be protected: a repository containing privileged configuration is a security-sensitive asset, and automated changes require testing, review, rollback, and secret management.

Emerging environments increasingly use short-lived identities, SSH or infrastructure certificates, centralized identity providers, hardware-backed keys, and just-in-time privilege. Containers and cloud platforms add identities such as workload roles and service accounts. These do not replace Linux fundamentals; they extend them. The same questions remain decisive: who is acting, what may the identity do, for how long, and how can the action be verified?

Best-Practice Checklist

• Prefer named human accounts over shared accounts.
• Use groups for role-based access and review membership regularly.
• Disable or remove unused accounts and revoke associated keys.
• Use sudo with narrowly defined commands and validate policies with `visudo`.
• Protect SSH private keys and restrict automation keys.
• Audit ACLs, setuid files, capabilities, and privileged groups.
• Apply secure umasks and avoid broad world-writable permissions.
• Test PAM and privilege changes with recovery access available.
• Separate development, approval, deployment, and operational duties.
• Centralize relevant logs and periodically recertify access.
• Manage identity configuration as reviewed, version-controlled code.

Chapter Summary

Linux access governance combines identity, authentication, authorization, and accountability. Users and groups establish organizational roles; ownership, modes, ACLs, and capabilities express authorization; PAM controls authentication and account policies; sudo provides auditable privilege elevation; and SSH keys enable strong remote identities. Profiles influence execution context, while quotas protect shared resources. Effective administration applies least privilege and separation of duties throughout the account lifecycle. Secure implementation also requires review, monitoring, automation controls, and reliable revocation processes.

Key Terms

UID: Numeric identifier assigned to a Linux user.

GID: Numeric identifier assigned to a Linux group.

Primary group: The group associated by default with a user’s newly created files.

Supplementary group: An additional group whose permissions a user may use.

Service account: An identity used by an application or daemon rather than a person.

Least privilege: Granting only the access required for an approved task.

Separation of duties: Dividing sensitive responsibilities among different identities or roles.

PAM: Modular framework for authentication, account, password, and session policies.

sudo: Mechanism for controlled execution of commands as another user.

ACL: Extended permission list that grants access to named users or groups.

Umask: Process setting that removes permissions from newly created objects.

Setuid: File attribute causing an executable to run with the file owner’s effective UID.

Linux capability: Narrow privilege representing a specific administrative operation.

Quota: Limit on a user’s or group’s storage or inode consumption.

SSH public key: Public component of a cryptographic identity used for authentication.

Authorized keys: Server-side list of public keys permitted for an account.

Identity lifecycle: Processes governing account creation, use, review, suspension, and removal.

Privilege escalation: Obtaining authority beyond the permissions initially assigned.

Effective permissions: Access actually available after masks and applicable rules are considered.

Review Questions

Short Answer Questions

1. Why are numeric UIDs and GIDs significant to the Linux kernel?

2. Distinguish a primary group from a supplementary group.

3. What is the purpose of the sudoers file?

4. How does an ACL extend traditional Unix permissions?

5. Why should service accounts generally not have interactive shells?

Long Answer Questions

1. Explain the Linux account lifecycle and the administrative controls required at each stage.

2. Compare traditional permissions, ACLs, and capabilities, including suitable use cases for each.

3. Discuss how PAM contributes to authentication, account management, and session security.

4. Explain how SSH public-key authentication should be designed for both human administrators and automation.

5. Describe how least privilege and separation of duties can be implemented on a production Linux host.

Analytical / Application Questions

1. A user can read a file according to `ls -l`, but an application reports “permission denied.” Develop a diagnostic procedure that considers directory traversal, ACLs, identity resolution, profiles, and security policy.

2. Design an access model for a CI system that must deploy an application but must not obtain a general root shell. Specify the account, SSH key restrictions, file permissions, sudo policy, and audit controls.

3. An employee’s password is locked, but security logs show continued access through SSH. Analyze how this could occur and propose a complete revocation procedure.

22. Multiple Choice Questions with Answers

Question 1

A user belongs to a group, but a file’s group permission does not provide the expected access. Which explanation is most appropriate?

A. The user’s UID is always ignored by Linux

B. An ACL mask or another path permission may restrict effective access

C. Group permissions apply only to root

D. The file must be owned by the user personally

Correct Answer: B. An ACL mask or another path permission may restrict effective access

Question 2

Why is the command `usermod -aG developers alice` preferable to `usermod -G developers alice` when adding a group?

A. It changes Alice’s UID

B. It preserves existing supplementary-group membership

C. It disables Alice’s password

D. It changes the primary group automatically

Correct Answer: B. It preserves existing supplementary-group membership

Question 3

Which sudo policy best reflects least privilege for a release team?

A. Allow the team to run every command as root without a password

B. Allow only specified service-management commands with explicit paths

C. Add every team member to the root group

D. Give the team write access to `/etc`

Correct Answer: B. Allow only specified service-management commands with explicit paths

Question 4

What is the principal security advantage of named administrator accounts over a shared root account?

A. Named accounts require no authentication

B. Named accounts make actions attributable to individuals

C. Named accounts automatically prevent all privilege escalation

D. Named accounts eliminate the need for logging

Correct Answer: B. Named accounts make actions attributable to individuals

Question 5

Which statement about directory execute permission is correct?

A. It permits modification of every file in the directory

B. It permits traversal and access to entries when other permissions allow it

C. It makes the directory searchable only by root

D. It is identical to file execute permission

Correct Answer: B. It permits traversal and access to entries when other permissions allow it

Question 6

A deployment SSH key should be restricted with a forced command primarily to:

A. Allow the key to authenticate without a public key

B. Limit the key to its intended automation function

C. Make the private key publicly readable

D. Grant unrestricted root access

Correct Answer: B. Limit the key to its intended automation function

Question 7

What is the main danger of granting a program a powerful Linux capability?

A. The program can never run as a service

B. A vulnerability in the program may expose the associated privileged operation

C. The capability changes the file’s username

D. Capabilities disable all auditing

Correct Answer: B. A vulnerability in the program may expose the associated privileged operation

Question 8

Why should PAM changes be tested with recovery access available?

A. PAM affects only file compression

B. A configuration error can prevent legitimate administrative logins

C. PAM automatically deletes user accounts

D. PAM changes disk quotas only

Correct Answer: B. A configuration error can prevent legitimate administrative logins

Question 9

Which control most directly prevents a shared filesystem from being exhausted by one user?

A. A disk quota

B. An SSH host key

C. A shell alias

D. A group name

Correct Answer: A. A disk quota

Question 10

In the illustrative deployment-host case, why was the CI account given a restricted SSH key and staging access?

A. To ensure it could modify every system file

B. To reduce its authority to the deployment task it actually performs

C. To avoid keeping any deployment logs

D. To allow developers to use its private key

Correct Answer: B. To reduce its authority to the deployment task it actually performs