Explain file permissions and how you'd debug a permission denied error

Crisp answer: Linux permissions are a 9-bit mask on every file: read, write, execute for owner, group, and others. A permission denied error means the process's effective UID/GID doesn't have the required bit set.

The permission model:

-rwxr-x---  1  joyson  engineers  4096  Jun 1  script.sh
 |||||||___  others:  no permissions (---)
 ||||___     group:   read + execute (r-x)
 |___        owner:   read + write + execute (rwx)
 |           file type: - = regular, d = directory, l = symlink

Numeric equivalents:

rwxr-xr-- = 754. rwx = 4+2+1 = 7. r-x = 4+0+1 = 5. r-- = 4+0+0 = 4.

Common permission modes:

chmod 644 file      # Owner: rw, group: r, others: r — standard file
chmod 755 script    # Owner: rwx, group: rx, others: rx — executable
chmod 600 private   # Owner: rw, nobody else — SSH keys, secrets
chmod 700 dir       # Owner: rwx only — private directory
chmod 777 dir       # Everyone rwx — never do this in production

Special bits:

chmod 4755 file     # SUID + 755
ls -l file          # Shows 's' in owner execute bit: -rwsr-xr-x

Debugging a permission denied error — the checklist:

# 1. What user is the process running as?
whoami
id                  # Shows UID, GID, and all supplementary groups

# 2. What are the permissions on the file/dir?
ls -la /path/to/file
stat /path/to/file  # More detail: inode, permissions, owner, size

# 3. Check the full path — every directory in the path needs execute (x)
namei -l /full/path/to/file  # Shows permissions for every component of the path

# 4. Check SELinux or AppArmor (common in production)
ls -Z /path/to/file          # SELinux labels
getenforce                   # Enforcing / Permissive / Disabled
ausearch -m avc -ts recent   # SELinux audit log (permission denied)
aa-status                    # AppArmor status

# 5. Check ACLs (extended permissions beyond owner/group/other)
getfacl /path/to/file        # Are there ACL entries overriding standard perms?

# 6. Is the filesystem mounted read-only?
mount | grep /dev/sda        # Check mount options
cat /proc/mounts

The directory execute bit gotcha:

To access a file, you need execute (x) on every parent directory in the path, even if you don't need to list the directory. r on a directory lets you list its contents. x on a directory lets you enter it. Many bugs come from a directory missing x for the relevant user.

namei -l /var/app/config/settings.yaml
# Shows: drwxr-xr-x  /
#        drwxr-xr-x  var
#        drwxr-x---  app    ← group has no x, or user isn't in the group
#        ...

What to say in the interview:

"First check what user the process is running as with id. Then ls -la on the file to see the permission bits. Then namei -l on the full path — because you need execute on every directory in the path, not just the file itself. If that all looks right, check SELinux or AppArmor with getenforce and ls -Z — those add a second layer of access control that standard permission checks won't show."