Linux account security is not controlled by one file or one command. Authentication, password storage, privilege elevation, ownership, mode bits, access control lists, and default file-creation permissions are separate layers. A secure system depends on understanding what each layer can decide and, just as important, what it cannot decide.

The Linux Professional Institute still lists LPIC-1 102-500 as the current second exam for LPIC-1. Its administration and security objectives make account control a practical part of the broader LPI certifications path. The operational skill is to trace an access decision from identity through authentication and authorization instead of treating “permission denied” as one generic problem.

Account identity begins with users, groups, and shadowed credentials

Local user information is traditionally represented through files such as /etc/passwd, while password hashes and password-aging data are protected in /etc/shadow. The separation exists because many programs need access to basic account identity information, but password hashes should not be world-readable. Modern systems may also integrate directory services, identity providers, or centralized authentication, yet the local-account model remains foundational.

An account has more than a username. The numeric UID is what the kernel uses for ownership decisions, and group membership adds one or more GIDs to the security context. That is why manually changing an account name does not necessarily change ownership semantics, while reusing a numeric UID can unintentionally give a new account access to files owned by the old identity.

Password aging, account expiration, login shell, and locked-password state are different controls. Disabling interactive login can be appropriate for service identities, while password locking does not necessarily prevent every form of authentication if other credentials or mechanisms remain available. Administrators should decide what capability must be removed rather than assuming one account flag closes every path.

PAM controls authentication flows, not Unix file permissions

Pluggable Authentication Modules, or PAM, provide a framework through which applications can use configurable authentication, account, session, and password-management modules. A login service, SSH service, or privilege tool can have a PAM policy that chains several modules. That makes PAM powerful, but it also means a configuration mistake can affect many users at once.

PAM answers questions such as whether an authentication attempt is acceptable, whether an account is allowed to use a service, whether session actions must run, or how password changes are handled. It does not replace normal file ownership and mode checks. A user can authenticate successfully and still lack permission to read a file; conversely, a process may have filesystem permission to access data even though interactive login is disabled for the account that owns the process.

When authentication fails after a PAM change, preserve an administrative recovery path and inspect logs before changing multiple modules at once. Module order and control flags influence whether a failure is decisive, ignored, or combined with later results. PAM configuration is therefore best changed incrementally and tested through the exact service being secured.

Use sudo to delegate specific privilege instead of sharing root

The sudo model lets administrators authorize users or groups to run selected commands with elevated identity. That is safer and more auditable than distributing a shared root password because the policy can be scoped and activity can be attributed to individual accounts. sudo and su provide useful background, but secure delegation requires more than knowing how to switch identities.

A strong sudo rule grants the minimum command set needed for an operational task. Broad permissions such as unrestricted shell execution effectively grant full root access even if the rule appears to name one utility. Administrators must consider whether the allowed program can spawn a shell, edit arbitrary files, load plugins, invoke other commands, or write to paths later executed by privileged processes.

Editing sudo policy through validation-aware tools reduces the risk of locking out administrators with a syntax error. Policy should also favor groups and role-like abstractions over one-off user rules where possible. When responsibilities change, removing a user from a privileged group is cleaner than hunting through scattered policy fragments.

Mode bits are the first filesystem authorization layer

Traditional Unix permissions define read, write, and execute rights for an object’s owner, group, and everyone else. Directories interpret those bits differently from ordinary files: read controls listing names, write controls creating or removing directory entries, and execute controls traversal and access to entries. Misunderstanding directory execute permission is a common cause of confusing access failures.

The existing article on Linux UID, GID, and file permissions provides a useful foundation. For security administration, extend that model to ownership changes, group strategy, inheritance behavior, and special bits. Setuid, setgid, and sticky semantics can materially change how executables and shared directories behave; setuid, setgid, and sticky-bit permissions are especially relevant when reviewing privileged files and shared directories.

Permissions should be analyzed on the whole path, not just the final file. A user may have read permission on a file but be unable to traverse a parent directory. Similarly, write permission on a directory can allow deletion or replacement of a file even when the user cannot modify the file’s contents directly.

ACLs add exceptions when owner/group/other is not enough

POSIX access control lists can grant or restrict permissions for additional named users and groups without changing the basic owner or group of a file. They are useful when a resource must be shared across organizational boundaries that do not fit one Unix group cleanly. But they also add another layer that must be checked when visible mode bits appear to allow or deny access unexpectedly.

The ACL mask is particularly important because it can limit the effective permissions of named users, named groups, and the owning group. An ACL entry may visually show write permission while the mask removes it from the effective result. Good troubleshooting therefore uses ACL-aware inspection rather than reading only the three traditional mode triplets.

Default ACLs on directories can shape permissions inherited by newly created entries. They are not retroactive controls for every existing file, and application behavior can still influence creation modes. Administrators should test how default ACLs interact with the process’s requested mode and the filesystem’s normal rules.

umask restricts requested permissions at creation time

A process creates a file or directory with a requested mode, and the umask removes selected permission bits from that request. This means umask is not a permission that is “applied later” to every object. It affects creation and normally does not change permissions on existing files. Different shells, services, and systemd units can run with different umask settings.

A common mistake is to assume a restrictive umask guarantees sensitive data remains private. An application can explicitly change permissions after creation, an ACL may grant access, a service may use a different umask, or files may be copied with preserved metadata. Umask is one preventive default, not a complete data-protection policy.

For shared group workflows, a deliberately chosen umask and directory setgid behavior can make new files remain group-collaborative without being broadly accessible. For secrets, the design should start from the opposite direction: grant only the identities that truly need access and verify the actual resulting mode and ACL.

Troubleshoot access denials by following the decision path

When a user cannot perform an action, identify where the denial occurs. Can the user authenticate? Is the account permitted to use the service? Does sudo policy authorize the command? What UID and groups does the process actually have? Can it traverse every directory in the path? What do the file mode bits, ACL, and mount options say? Are additional security systems such as SELinux or application-level authorization involved?

This order matters because changing file modes will not fix a PAM denial, and changing a password will not fix a directory traversal problem. Likewise, adding a user to a group may not affect already-running sessions until group membership is refreshed. Evidence should come from the exact failed operation and the process credentials involved.

For LPIC-1 preparation, create lab accounts and deliberately build controlled permission scenarios. Combine groups, sudo rules, ACLs, default ACLs, umasks, and directory permissions. Then predict the result before testing it. Account security becomes much easier when every control is understood as a specific decision layer instead of a collection of unrelated commands.

Service accounts and non-password credentials need deliberate controls

Many Linux identities exist for daemons, scheduled jobs, automation, and application ownership rather than for people. A service account should normally have only the filesystem access, group membership, and execution rights required by that service. Giving it an interactive shell or broad sudo access “just in case” expands the impact of a compromised process without adding useful resilience.

SSH keys, API tokens, and other non-password credentials also change the access model. Locking a local password does not automatically revoke an authorized SSH key, and removing interactive shell access may still leave a service credential usable by a process. Offboarding and incident-response procedures should enumerate every credential type tied to an identity, including keys in home directories, sudo permissions, scheduled jobs, service files, and centralized identity mappings.

File ownership deserves special attention when deleting accounts. Files are owned by numeric UIDs, so removing the username does not erase that ownership. If a new account later receives the same UID, it can inherit access to old files unexpectedly. Periodic searches for orphaned numeric owners and a controlled UID-allocation policy help prevent identity reuse from becoming an authorization mistake.