Linux permissions beyond rwx: umask, the sticky bit, setuid and hard links

This is AI-assisted: I built it from our Linux glossary entries with an AI tool's help and checked the behaviour against the man pages. I run LearnSome.tech, where the glossary lives; nothing below needs an account anywhere.

Everyone learns rwx and chmod 644 early. Then something odd happens: a new file comes out with permissions nobody set, or you can write to a directory but can't delete a file in it. These four words explain most of it.

umask: where default permissions come from

New files start from 666 and new directories from 777, and the umask removes bits from both. With the common umask 022, files come out 644 and directories 755. With 077, nobody but you gets any access.

umask          # show the current mask, e.g. 0022
umask 077      # this shell and the programs it starts: private by default
touch secret.txt && ls -l secret.txt   # -rw-------

The umask is inherited by child processes, so a service started with a loose umask writes loose files.

The sticky bit: why you can't delete someone else's file in /tmp

/tmp is writable by everyone, yet you can't remove another user's file in it. That's the sticky bit: on a directory, it lets users delete or rename only their own files.

ls -ld /tmp    # drwxrwxrwt: the trailing t is the sticky bit
chmod 1777 shared/   # the leading 1 sets it in octal

It adds a rule about removing names. It doesn't replace the normal read, write and search permissions.

setuid: running as the file's owner

A setuid executable runs with its owner's identity, not the identity of whoever started it. That's how passwd, owned by root, can update a file an ordinary user can't touch.

It also means every setuid-root program is part of your security perimeter: a flaw in one can hand an attacker root. Keep them few, owned by root, not writable by anyone else, and know which ones you have:

find / -xdev -perm -4000 -type f 2>/dev/null   # list setuid files on this filesystem

Hard links: one file, two equal names

A file's data and metadata live in an inode; a name in a directory just points at it. A hard link is a second name for the same inode. Neither name is the "original": edit through one and the other sees it, because there's only one file.

ln report.txt report-copy.txt
ls -li report*.txt   # same inode number, link count 2

That explains a classic surprise: deleting a name doesn't free the space while another hard link still points at the inode. It also explains why a filesystem can run out of inodes while it still has free space.

The one-line takeaway

When permissions surprise you, check four things: the umask that created the file, any special bits on the directory, any special bits on the program, and how many names point at the inode (ls -li).

Which of these surprised you most when you first ran into it?