SUID, SGID, sticky & umask
The special bits attackers look for.
Beyond rwx there are three special permission bits, and two of them are exactly what attackers hunt for, so a DevSecOps engineer must understand them. The most important is SUID (Set User ID): when set on an executable, the program runs with the privileges of the file’s owner, not the user who ran it. A SUID-root binary lets an ordinary user execute code as root — which is intended for a few trusted tools (like passwd) and a disaster if it lands on the wrong binary.
$ ls -l /usr/bin/passwd-rwsr-xr-x 1 root root ... /usr/bin/passwd# ^ the "s" in the owner’s execute slot = SUID: runs as root (the owner) for any caller# audit every SUID-root binary on a host — each is a potential escalation path:$ find / -perm -4000 -type f 2>/dev/null
SGID and the sticky bit
SGID (Set Group ID) is the group equivalent: on a program it runs with the file’s group; on a directory (more usefully) it makes new files inside inherit the directory’s group, which is how shared team directories keep consistent group ownership. The sticky bit, set on a directory, means only a file’s owner can delete it — which is why /tmp is world-writable yet users cannot delete each other’s files. You will see it as a t in the others-execute slot (drwxrwxrwt on /tmp).
$ ls -ld /tmpdrwxrwxrwt 10 root root ... /tmp # the "t" = sticky: anyone writes, only owners delete$ chmod 2775 /srv/shared # SGID (2): new files inherit the "shared" group$ chmod 1777 /srv/dropbox # sticky (1): shared write, no deleting others’ files
umask: the permissions new files get
When you create a file, its permissions are decided by the umask — a mask that subtracts from the default. The typical umask of 022 means new files are 644 (rw-r--r--) and new directories 755, i.e. world-readable. On a system handling sensitive data you may set a stricter umask like 027 (new files 640, no access for others) so that nothing is world-readable by accident. It is a quiet but real hardening setting.