OpsQuest
ProgressSign in

Permissions and least privilege

Access is decided along the whole path, and a process should hold only the rights its job needs.

Unix permission checks happen at every directory on the path, not only on the final file. To open /srv/reports/q3/report.csv you need execute (search) permission on /srv, /srv/reports, and /srv/reports/q3, and read permission on the file. A group-readable file inside a directory the group cannot traverse is unreachable. That is the classic "the file says I can read it, but I can't".

Read the mode string by audience. -rwxr-x--- grants the owner read, write, and execute, the group read and execute, and everyone else nothing. On directories, r lists names, x lets you pass through, and w lets you create and remove entries, including other people's files unless the sticky bit is set.

Least privilege means granting the narrowest access that still lets the job run:

  • A container that binds port 8080 and writes one state directory has no reason to run as root. Create a user, give it ownership of that directory only, and leave the application code read-only to it.
  • Access rules like SSH AllowGroups should name the group that needs access. Replacing them with a wildcard fixes today's ticket and opens tomorrow's incident.
  • "Make it 777" is never a diagnosis. It hides which permission was actually missing and widens access for everyone.

When you change access, test both directions. Confirm that the intended principal now succeeds and that an unrelated principal still fails. A repair that only tests the first is half verified.

Cloud accounts apply the same idea with policies instead of mode bits. An IAM policy attached to a role says what that identity may do. A resource policy, such as an S3 bucket policy, says who may touch that resource, and "Principal": "*" means anyone on the internet. Within one account a request is allowed if either side allows it and nothing denies it. Least privilege here means naming the actions a job really calls and the resources it really touches. Build the list from the job itself, not from a wildcard that "makes it work". A deploy role reachable from CI is as powerful as the weakest path to merging a workflow.