Skip to content

Practise File Permissions Without Changing System Files

Use disposable files to learn what a permission change actually denies. Changing /etc, your SSH directory or a shared project is not necessary for a first exercise.

Outcome: observe a successful read, a refused write, and a restored write as the same ordinary user. Complete the update lesson first, or begin here with basic terminal skills. This lab requires Bash, GNU coreutils and a local filesystem that supports Unix modes.

What the permission bits describe

Linux files have an owner and group. The familiar mode bits give owner, group and other users read, write and execute permissions. For a regular file, execute is permission to run it as a program; for a directory, execute permits searching/traversing it.

Mode 600 means owner read/write, no group or other permissions. 400 means owner read only. 700 on a directory restricts ordinary traversal to its owner. These are traditional mode bits, not a complete model of ACLs, capabilities, privileged processes or every filesystem's behavior. See GNU's file-permission documentation.

The owner can usually change their own file's mode again. That makes this a demonstration of accidental-write protection, not a boundary against malicious code running as the same owner. A separate service account or sandbox is a different control.

Run the complete disposable-file lab

Run this whole block in Bash on the Pi as your ordinary login user. Do not prefix it with sudo. It refuses a root session because root may bypass the denial being demonstrated.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
(
    set -eu
    if [ "$(id -u)" -eq 0 ]; then
        printf 'Use an ordinary user, not root.\n' >&2
        exit 1
    fi
    umask 077
    permissions_lab=$(mktemp -d /tmp/pi-security-permissions.XXXXXXXX)
    printf 'Practice directory: %s\n' "$permissions_lab"
    printf 'Disposable example, not a real secret.\n' > "$permissions_lab/note.txt"
    stat -c '%a %U:%G %n' "$permissions_lab" "$permissions_lab/note.txt"

    chmod 400 "$permissions_lab/note.txt"
    cat "$permissions_lab/note.txt"
    if printf 'This write should fail.\n' >> "$permissions_lab/note.txt"; then
        printf 'Unexpected write success: stop and inspect your environment.\n' >&2
        exit 1
    else
        printf 'Expected: the owner write was refused.\n'
    fi

    chmod 600 "$permissions_lab/note.txt"
    printf 'Writing works again after restoring mode 600.\n' >> "$permissions_lab/note.txt"
    stat -c '%a %U:%G %n' "$permissions_lab/note.txt"
    cat "$permissions_lab/note.txt"
)

Expect the directory to start at 700, the file at 600, a readable file after the change to 400, and a Permission denied message for the attempted append. The final mode is 600; the file has the original line and the successful final append, not the failed append.

The subshell keeps lab variables and umask changes out of your interactive shell. No existing file is overwritten. Each run creates a different directory.

Check the result instead of guessing

The successful final read proves that the original content remains accessible to you. The refused append proves a denial under this account in this environment. It does not test another user's access, a remote shared filesystem, or a root process.

If the write unexpectedly succeeds, stop: you may be privileged or using a filesystem with different semantics. If chmod fails, do not “fix” it by applying recursive permissions elsewhere. Check the filesystem and use a fresh ordinary-user practice environment.

To repeat, rerun the block. For cleanup, use the printed path to inspect and remove only its note.txt, then remove that now-empty practice directory. A file manager is sufficient. Do not substitute a recursive delete of /tmp or a home/project directory. The tiny private lab is also safe to leave until your normal temporary-file cleanup.

Apply the lesson to credentials

Do not make a token readable by everyone to silence a service error. Identify which user needs it, how parent-directory traversal works, and whether a separate service identity is appropriate. A private file does not protect a secret from code already running as its owner or from a privileged administrator.

Keep real passwords and private keys out of exercises, Git repositories, screenshots and shared diagnostic logs. Permissions restrict access; encryption and an independent backup have different jobs.

Checkpoint and next step

Why can the file owner restore write permission? Why is chmod 400 not enough to isolate an untrusted application running under that same user?

The disposable-file lab was checked with an ordinary user on the verification Pi; see the course verification scope. For broader ownership/group practice, see users and permissions.

Next: verify SSH access and recovery without locking yourself out. Return to Security.

Donate