Understand who can access a file, why a command needs extra privileges, and how to prepare a private handover without giving a script unrestricted administrative power.

Series: Previous: text · Part 3 of 6 · Next: monitoring
Applies to: Linux discretionary permissions, GNU Coreutils, sudo and shadow-utils. Account-management commands are lab examples requiring appropriate authorization, not instructions to change a shared server.

The subsystem: identities and access checks

A process has user and group identities. A file has an owner, group and access mode. The kernel uses those identities and other security controls to decide whether an operation is permitted. Ordinary permissions are only part of the picture: ACLs, SELinux/AppArmor, read-only mounts and service confinement can also affect access.

For a directory, read permits listing names, execute permits traversal and write permits changing entries, subject to other rules. A process needs traversal permission on parent directories to reach a file. Deleting a file depends largely on permissions on its parent directory, not simply whether the file is writable.

In a large organization, access should match a role and an approved task. The goal is to let an operator inspect a service log without casually granting the ability to replace every service binary.

sudo: run an authorized command as another identity

sudo -l
sudo -u service-reader -- id

The first inspects your permitted sudo actions; policy may require authentication. The second is illustrative and works only if that account exists and policy permits it. sudo defaults to root when no target user is specified, but it does not inherently mean “run as root.” It applies the configured policy.

Prefer a reviewed, narrowly scoped command over opening an unrestricted shell. Authentication success does not authorize unrelated operational changes. Never place a password in a command line or pipe one into a published script.

su: switch identity and start a shell

su - labuser

On a lab host with that account, this starts a login-style shell as labuser, normally after authentication. exit returns to the previous shell. The hyphen requests a login environment; working directory and environment can change. Unlike a narrowly permitted sudo command, an interactive identity switch can make the scope of subsequent actions less obvious. Verify id before making a change.

chmod: change access permissions

Use a disposable fixture owned by your current user:

lab=$(mktemp -d)
printf 'sample report\n' > "$lab/report.txt"
chmod 600 -- "$lab/report.txt"
ls -l -- "$lab/report.txt"

Expect the mode to begin -rw-------: owner read/write, no ordinary group or other access. Symbolic modes such as chmod u+x script.sh add just the requested bit. chmod 777 is not a general solution to permission problems. Avoid recursive changes to an application tree without understanding executable files, directory traversal and special permission bits.

chown: change ownership

For an approved lab account and group that actually exist:

sudo chown labservice:labteam -- /srv/lab-app/report.txt
ls -l -- /srv/lab-app/report.txt

This changes the owner and group, not the contents. Changing ownership generally requires additional privilege. Use an exact file path and inspect the result; recursive chown can affect much more than intended. Ownership changes can also alter special mode bits or interact with application access. The handover script below does not need chown because its files should stay with the current user.

passwd: manage account passwords interactively

passwd

With the account’s permitted authentication mechanism, this requests a change to your own local password. The password is entered at the prompt rather than stored in history. An administrator can target another account, but that is a separate authorized operation and may not apply to a centrally managed identity. Do not assume changing a local password rotates LDAP, SSO, application or SSH-key credentials.

Some service accounts are intentionally locked and do not need interactive passwords. In enterprise environments, follow the identity team’s recovery and credential-lifecycle process rather than setting a password as a troubleshooting shortcut.

Practical script: prepare a private review package

A support engineer needs a private working copy of a report before reviewing and redacting it. Save as private-handover.sh; run bash private-handover.sh ./sample-report.txt. Use a non-sensitive lab report first.

#!/usr/bin/env bash
set -euo pipefail
umask 077
if (( $# != 1 )) || [[ ! -f $1 || ! -r $1 ]]; then
  printf 'Usage: bash private-handover.sh READABLE_REPORT\n' >&2
  exit 2
fi
review_dir=$(mktemp -d)
chmod 700 -- "$review_dir"
cp -- "$1" "$review_dir/report.txt"
chmod 600 -- "$review_dir/report.txt"
printf 'Review directory: %s\n' "$review_dir"
printf 'Owner and permission evidence:\n'
ls -ld -- "$review_dir" "$review_dir/report.txt"
printf 'Review and redact this copy before sharing it.\n'

The directory mode should be drwx------ and the file mode -rw-------. The script changes only its newly created files and needs no sudo rights. It does not change the original report. Keeping the private directory in place avoids deleting evidence before review.

A private mode does not encrypt the report or prevent access by privileged administrators. Do not use a real secret as a lab fixture. If a receiving service needs access, make that a separate reviewed ownership or group-access step rather than embedding privilege escalation in this script.

Troubleshooting and references

If a readable file still cannot be reached, inspect its parent-directory permissions. If Unix mode bits appear correct, check ACLs and the platform’s security policy with the responsible administrator. Avoid changing multiple controls at once; a narrow change is easier to understand and reverse.

References: sudo manual, Linux path resolution, GNU chmod, GNU chown, shadow-utils manuals.

FILED UNDER