Sal can read the file but not reach it OPS-771

Read a mode string, predict access for any user, and grant only what a job needs.

One question, three classes

Every access check the kernel performs on a file asks the same question: which class does this process belong to? The process is the owner class if its user ID matches the file's owner. Otherwise it is the group class if one of its groups matches the file's group. Otherwise it is other. Exactly one class applies, and only that class's three bits are consulted. A frequent surprise follows: a file owned by you with mode 0077 is unreadable to you even though everyone else can read it.

The symbolic form rwxr-x--- lists the three classes left to right. Each triple maps to an octal digit: read is 4, write is 2, and execute is 1. So rwx is 7, r-x is 5, and --- is 0, giving 750. Learn to read both forms quickly. Runbooks and configuration tools tend to use octal, and ls -l shows symbols.

Directories are lists of names

A directory is a table mapping names to files, and its bits mean something different:

• read lets you list the names (ls).
• write lets you add, remove, or rename entries. You can delete a file you cannot write, if you can write its directory.
• execute (search) lets you use the directory in a path to reach what is inside.

The last one causes the most confusing incident on this topic. A report can be group-readable, the user can be in the group, and the open still fails. One directory on the path lacks execute for that user. namei -l /full/path prints the owner and mode of every component, which turns the hunt into one command.

Identity is numbers

Names such as deploy and oncall are a convenience. The kernel stores numeric user and group IDs, and /etc/passwd and /etc/group (or a directory service) map them to names. Two consequences matter in operations. First, files restored from another host may show odd owners if the numbers differ there. Second, a process's group list is fixed when it starts. Adding a user to a group does not help a shell that is already open. They need a new login session.

Changing access with the smallest grant

chmod changes bits, chgrp changes the group, and chown changes the owner (normally only root can give a file away). The symbolic forms make intent obvious: g+x reads as "let the group execute". Before granting, name the actor and the action. "On-call engineers must run the rotation script" leads to g+x on that file, with the group already set to oncall. It does not lead to 777, which also lets every account on the host rewrite the script that on-call engineers later run.

umask shapes the default. Programs request a mode, typically 666 for files and 777 for directories, and the umask removes bits from it. Service accounts often run with 027 so new files are invisible to other users. If a service creates files that a reader cannot open, look at the creating process's umask before you start running chmod on files.

Escalation is a tool, not a habit

sudo runs one command as another user, usually root, and records it. Use it for the one command that needs it, not to run a whole investigation. Reading as an ordinary user shows what the service experiences. Root's view hides exactly the permission problems you are trying to find.

Key terms

Mode

Nine permission bits in three classes (user, group, other), plus special bits. Shown as rwxr-x--- or octal 750.

Execute on a directory

Permission to traverse it, that is, to use it as part of a path. Without it, even readable files inside are unreachable.

umask

Bits removed from the default mode of newly created files. A umask of 027 yields 640 files.

Least privilege

Granting exactly the access a task needs and nothing broader.

Read further

• The Linux Command Line, Chapter "Permissions" (Free PDF (CC BY-NC-ND))
  The ls -l attribute string, octal notation, chmod in symbolic form, umask, and the section on changing identities with su and sudo. Notice the table of what each bit means on a directory.
• How Linux Works, 3rd edition, Ch. 7, "System Configuration — Logging, System Time, Batch Jobs, and Users" (Purchase)
  The sections on user IDs and the /etc/passwd and /etc/group files. Note that the kernel works with numeric IDs, and names are a lookup.

Restore SSH access without widening it, and keep installed software the same across a fleet.

Access is a chain

An SSH login passes through several independent checks, and any one can refuse:

1. Network: can the client reach port 22, or a firewall or VPN in between?
2. Server policy: AllowUsers, AllowGroups, DenyGroups, and PermitRootLogin in the effective configuration. sshd -T prints it after includes and Match blocks.
3. Account: does the account exist, and is it locked or expired, with a valid shell?
4. Key: is the public key in ~/.ssh/authorized_keys, and is the client offering the matching private key?
5. File safety: with StrictModes on (the default), sshd ignores key files that others could modify, including through a group- or world-writable home or .ssh.

Work the chain with evidence from both ends. ssh -v shows what the client offered and where it stopped. The server's auth log (journalctl -u ssh or -u sshd) usually states the reason plainly, for example "User sal from 10.0.4.7 not allowed because none of user's groups are listed in AllowGroups".

Groups change at login

Group membership is copied into a process when the session starts. Adding someone to a group changes the directory, but their open shells keep the old list. id shows the session's groups. This also matters for server policy. After a directory migration renames a group, every rule that names the old group, in sshd_config, in sudoers, or in file ownership, silently stops matching.

When access breaks after a migration, the fix is to update the rule to the new group, not to add individual users. Granting to roles keeps the next review short and the next revocation complete.

Shared accounts and privilege

The handbook argues for individual accounts with sudo over shared logins. Individual accounts give you accountability, because logs name a person, and clean revocation, because removing one person does not rotate everyone's password. Grant sudo for specific commands where possible, to groups rather than people, and log it.

Software is part of the host's state

Package managers keep a database of what is installed and from which repository. The questions to ask during "one host behaves differently":

apt-cache policy label-renderer     # installed, candidate, and which repo provides each
dpkg -l label-renderer
dnf list --showduplicates label-renderer
rpm -q --last | head                # recently changed packages

Drift creeps in through manual installs, uneven upgrade timing, a node pointing at a different mirror, or a pin applied on some hosts only. The remedy is to declare the version you want and apply it everywhere, which the Infrastructure as Code track's configuration management notes covers. Do that rather than hand-fixing the odd node.

Upgrade, pin, or roll back

When versions differ, decide deliberately. Roll back the odd node when the new version is the regression and you need service now. Pin (apt-mark hold, DNF versionlock) when a known-good version must stay until the incompatibility is fixed, and record why and until when. Upgrade the rest when the new version is correct and the odd node was simply early. In all cases, verify behaviour on each node, not just the version string.

Key terms

authorized_keys

Per-user file listing public keys allowed to log in. sshd ignores it if the file or its parent directories are writable by others.

AllowGroups

An sshd directive that restricts logins to members of the named groups. Anyone not in a listed group is refused even with a valid key.

Version pinning

Holding a package at a chosen version so routine upgrades do not change it (apt-mark hold, DNF versionlock).

Drift

Hosts that should be identical diverging over time, through manual changes or uneven upgrades.

Read further

• UNIX and Linux System Administration Handbook, 5th edition, Ch. 8, "User Management", and Ch. 3, "Access Control and Rootly Powers" (Purchase)
  How accounts and groups are stored, how sudo is configured, and the argument for least privilege. Note how the book recommends handling shared accounts.
• UNIX and Linux System Administration Handbook, 5th edition, Ch. 6, "Software Installation and Management" (Purchase)
  Package managers (APT and DNF/YUM), repositories and their trust, querying installed versions, and the section on keeping systems consistent.
• UNIX and Linux System Administration Handbook, 5th edition, Ch. 27, "Security" (Purchase)
  The SSH section, especially key-based authentication, the server configuration directives that restrict who may log in, and the guidance on root login.