Linux Permissions, ACLs and Privilege Delegation
Linux access control begins with a simple owner-group-other permission model, but real administration quickly adds default masks, special mode bits, access control lists, service accounts, and delegated privilege through sudo. The current CompTIA Linux+ XK0-006 objectives explicitly include chmod, chown, chgrp, umask, setuid, setgid, the sticky bit, setfacl, getfacl, sudoers, visudo, and related hardening controls.
The goal is not to memorize octal numbers in isolation. Administrators need to predict what a user can do, explain why access is denied, and make the smallest safe change. Familiarity with Bash command-line fundamentals helps because permission troubleshooting depends on reading ownership, executing commands in the correct context, and verifying results from the shell.
Read owner, group, and other permissions as three decisions
Traditional Linux mode bits assign read, write, and execute permissions separately to the file owner, the owning group, and everyone else. Use tools such as ls -l and stat to see the current mode and ownership before changing anything. A permission problem cannot be diagnosed reliably from the username alone because group membership and directory traversal rights also matter.
For regular files, read controls content access, write controls modification, and execute controls whether the file can be run as a program when other requirements are met. For directories, read lists names, write changes entries, and execute allows traversal into the directory. Directory execute permission is therefore essential even when a file itself appears readable.
Evaluate every directory in the path when a user cannot reach a file. A permissive file mode does not help if the user cannot traverse a parent directory. Use namei or step through the path deliberately instead of widening the final file to world-readable as a shortcut.
Use symbolic and octal chmod without losing intent
Symbolic chmod expresses changes such as adding group write or removing other execute, while octal mode expresses the complete owner-group-other bit pattern numerically. Both forms are valid; symbolic changes can be safer when you want to modify one permission without replacing unrelated bits. Read the existing mode before applying a full octal value copied from another system.
The familiar numeric values come from read=4, write=2, and execute=1 within each class. A mode such as 640 grants owner read/write, group read, and no access to others, but the correct mode depends on the service and data. Do not treat 755 or 644 as universal defaults without checking whether the file should be executable or public.
Recursive chmod can change thousands of files and directories with different functional requirements. Directories may need execute where regular files do not, and secrets may need tighter modes than surrounding content. Use find with separate file and directory rules when a tree requires controlled recursive repair.
Fix ownership with chown and chgrp before adding broad permissions
Many permission incidents are really ownership incidents: a service writes files as the wrong account, a backup restores ownership incorrectly, or an administrator copies files as root. Check user and group ownership before adding write access for everyone. Correct ownership often restores the intended access while preserving least privilege.
chown can change owner and group, while chgrp changes group ownership. When applying changes recursively, confirm mount points, symlinks, and service expectations so the operation does not cross into unrelated data. A recursive root-level ownership mistake can break services more severely than the original permission denial.
Use service accounts and functional groups to represent application access rather than repeatedly changing individual file owners. Group-based ownership makes multi-user collaboration and operational handoff easier to audit. Document why a service needs write permission so later hardening does not remove a legitimate dependency.
Control defaults with umask rather than repairing every new file
umask removes permissions from the creation mode requested by a process, shaping the default access of new files and directories. A restrictive umask can prevent accidental exposure, while an overly restrictive one can break collaboration and services. Document the control defaults with umask rather than repairing every new file decision point clearly enough that a temporary workaround cannot quietly become an undocumented permanent configuration. Check the process context because login shells, systemd services, applications, and containers may set different masks.
The mode a new file receives also depends on the creation mode requested by its process. Without a default ACL, a typical request for 0666 permissions combined with a 027 umask creates a 0640 file, while a request for a 0777 directory creates a 0750 directory. A service manager may define a different umask from an interactive login shell, and a directory default ACL can change the resulting effective rights. Inspect an actual file created by the service before assuming the shell’s settings explain its permissions.
Changing existing files with chmod does not change how future files are created. If the same permission defect returns every time an application writes a file, investigate the service umask, group strategy, or application configuration. Fix the creation policy rather than scheduling repeated corrective jobs.
Test defaults by creating a representative file and directory under the same account and service context. Interactive shell behavior may differ from a daemon launched by systemd. Verification should therefore reproduce the actual creation path that generated the problem.
Use setuid, setgid, and sticky bit only when their semantics fit
Setuid on an executable can run the program with the file owner’s effective identity, which is powerful and security-sensitive. Setgid can affect executable group identity and can also make new files in a directory inherit the directory’s group. Review special bits during hardening because an unnecessary privileged executable increases attack surface.
The sticky bit on a shared writable directory restricts deletion or renaming so users cannot remove each other’s files simply because the directory is writable. The classic use is a shared temporary directory. It does not encrypt content or prevent users from reading files whose modes allow read access.
Special bits appear in permission listings and can be overlooked when administrators focus only on the three octal digits. Use stat or explicit mode inspection when auditing sensitive paths. Removing a special bit without understanding the application can break legitimate privilege or collaboration behavior.
Use ACLs when the basic group model is not expressive enough
POSIX ACLs allow named users and groups to receive permissions beyond the single owner and owning group represented by traditional mode bits. getfacl shows the entries and setfacl modifies them, making ACLs useful for shared project directories and exceptions that would otherwise require awkward group restructuring. Prefer a clear group design when the access model is stable; use ACLs when additional specificity is genuinely needed.
The effective permissions of a named user or group ACL entry may be reduced by the ACL mask, even when `getfacl` shows more generous entry bits. When an account still receives “permission denied,” inspect the effective-rights annotation and every directory component along the access path. Default ACLs govern inherited entries for new children; changing a default ACL does not rewrite the permissions of every existing file. Test with the intended service identity before broadening mode bits, then record the minimum entry and mask that accomplish the actual task.
The ACL mask limits effective permissions for named users, named groups, and the owning group, so an entry that appears to grant write may still be effectively read-only. getfacl displays effective permissions when the mask restricts an entry. Troubleshoot the mask before repeatedly re-adding the same ACL permission.
Delegate administrative commands safely with sudo
sudo allows selected users to execute commands with elevated identity according to policy, avoiding routine root login for ordinary administration. The safest rule grants the smallest command set and target identity required for the role. Broad patterns, shells, editors, or commands that can launch arbitrary subprocesses may provide more privilege than the rule appears to grant.
Edit sudoers with visudo or validated files under /etc/sudoers.d so syntax errors are caught before they can lock out administrators. Group-based rules can scale delegation when job roles are well defined. Keep comments or change records that explain unusual exceptions because a technically valid sudo line can still violate policy.
Troubleshoot permission denied from path to policy
When a command returns permission denied, identify the exact operation: reading a file, writing a directory, executing a binary, binding a resource, traversing a path, or elevating privilege. When the symptom appears only after startup or a mount change, Linux boot and startup commands can help confirm whether the expected filesystem and service state exists before the access test runs. Document the troubleshoot permission denied from path to policy decision point clearly enough that a temporary workaround cannot quietly become an undocumented permanent configuration. Do not default to chmod 777 because it hides the cause and creates unnecessary exposure.
SELinux or another mandatory access-control layer can deny access even when Unix mode bits and ACLs appear correct. XK0-006 treats SELinux as part of Linux hardening, so administrators should check context and audit messages when ordinary permissions do not explain the denial. Changing SELinux to permissive globally is a diagnostic shortcut with significant security cost.
Audit permissions as part of routine hardening
Review world-writable files, unexpected SUID or SGID executables, sensitive files readable by broad groups, and sudo rules that grant shells or unrestricted package managers. Compare findings with application requirements and distribution defaults before removing access. A permission audit should produce explainable exceptions, not indiscriminate tightening that breaks production.
Linux career growth depends on understanding these controls as operations, not trivia; even broad discussions of Linux administration value ultimately rest on reliable ownership, privilege, and service management. Use version-controlled configuration, infrastructure automation, or compliance checks where they make recurring permission state observable. The strongest hardening practice is one that can detect drift and explain why each elevated permission still exists.