Permission & sudo Gotchas That Bite Everyone

Directory execute bits, SUID, sticky bits, sudo's stripped environment and safe sudoers edits.

You know rwx. The senior knowledge is the surprising cases where correct-looking permissions still deny access.

Directories need x, not r

On a directory, read lets you list names but execute lets you enter and access files inside. A directory with r-- and no x is a trap: ls works but every path through it fails with "Permission denied". To reach /a/b/file you need x on /a and /a/b.

Special bits

SUID (chmod u+s) — runs the program as its owner, not you. It is why passwd can edit /etc/shadow. A stray SUID root binary is a serious security hole — audit them.
Sticky bit (chmod +t, shows as t on /tmp) — in a shared directory, only the file's owner can delete their own files.

sudo strips your environment

sudo resets the environment for safety, so sudo mycmd may not see your PATH additions or exported variables. Use sudo -E to preserve the environment, or sudo env VAR=x cmd. And note sudo echo x > /root/f fails — the shell opens the file as you, before sudo runs; use ... | sudo tee instead.

Edit sudoers safely

Always use visudo. It syntax-checks before saving; a broken /etc/sudoers can lock everyone out of root.

Example

# Read on a dir lists names; execute is needed to actually use them
chmod 644 vault            # rw-r--r-- : a trap
ls vault                   # works: you can read the names
cat vault/secret.txt       # FAILS: no x, cannot traverse in
chmod 755 vault            # rwxr-xr-x : now traversal works

# Find SUID-root binaries (security audit)
find / -perm -4000 -user root -type f 2>/dev/null

# The redirect trap and the fix
sudo echo hi > /root/note        # bash: /root/note: Permission denied
echo hi | sudo tee /root/note    # works

# Preserve your environment through sudo when you must
sudo -E ./deploy.sh

# NEVER edit /etc/sudoers directly
sudo visudo

When to use it

A sysadmin uses 'chmod +t /shared/uploads' to set the sticky bit so users can only delete their own files in a shared upload directory.
A security auditor scans for SUID binaries with 'find / -perm -4000 -type f' to identify privilege escalation risks.
A developer discovers a 'Permission denied' error on a script inside a directory with execute bit removed, teaching the role of the directory x bit.

More examples

The directory execute bit

Shows that the directory execute (x) bit controls the ability to enter or traverse it, not just list files.

mkdir /shared
chmod 644 /shared    # no execute bit
cd /shared
# bash: cd: /shared: Permission denied

# Execute bit is required to enter a directory
chmod 755 /shared
cd /shared           # now works

Sticky bit on shared directory

Sets mode 1777 (sticky bit + full rwx) so all users can write but only owners can delete their own files.

# Create a shared directory writable by all
mkdir /shared/uploads
chmod 1777 /shared/uploads
# 1 = sticky bit: users can only delete their OWN files

ls -ld /shared/uploads
# drwxrwxrwt 2 root root 4096 Jul 16 /shared/uploads
#         ^ t = sticky bit

Audit SUID binaries

Scans for SUID/SGID binaries that run with elevated privileges; 's' in the execute position indicates the bit is set.

# Find all SUID binaries (run as owner, not caller)
find /usr /bin /sbin -perm -4000 -type f -ls 2>/dev/null

# Find SGID binaries (run as group)
find /usr /bin -perm -2000 -type f -ls 2>/dev/null

# Example: passwd is always SUID root
ls -l /usr/bin/passwd
# -rwsr-xr-x 1 root root 68208 /usr/bin/passwd

Discussion

Be the first to comment on this lesson.