Β§39.15–39.16Symbolic Links, Permissions, and Access Control

Part III OSTEP pp. 484–487 Β· ~7 min read

  • symbolic link
  • permission bits
  • access control list

Hard links are powerful but limited β€” you can’t hard-link a directory (cycle risk), and you can’t hard-link across file systems (inode numbers are only unique within one file system). A second kind of link lifts those limits.

A symbolic link (or soft link) is made with the same ln program plus -s. On the surface it looks like a hard link, but it is fundamentally different: a symlink is its own file, of a distinct type (the third type the file system knows, after regular files and directories). Its data is simply the pathname of the file it points to β€” so reading the link resolves through that path.

A symbolic link is a separate file whose data is a pathname. It resolves through that name β€” so if the target is removed, the link dangles.
file2symlink (its own file)data = "file"resolves path "file"fileregular file (inode)cat file2 β†’ hello (follows the path)

1ln -s file file2

A soft link (ln -s) makes file2 a NEW file of type "symlink" whose contents are the pathname "file". Reading file2 follows that path to the real file. Its size is just the length of the stored path (4 bytes for "file").

step 1 / 2

That path-based design is exactly why removing the target leaves a dangling reference β€” the link still holds the text of a path that no longer resolves. A hard link can’t dangle, because it keeps the inode alive through the link count. Here’s the full contrast:

Hard links vs symbolic (soft) links β€” two ways to give a file more than one name.
hard link (ln)symbolic link (ln -s)
What it isanother directory entry pointing at the same inodea separate file (a third type) whose data is a pathname
Copies data?nono
Own inode / file type?no β€” shares the target's inodeyes β€” its own little file
Size(same file)length of the stored pathname
Cross file systems?noyes
Link to a directory?noyes
If the target is removed?file survivesdangling reference
Dotted-underlined cells have explanations β€” click one.

39.16 Permission Bits And Access Control Lists

The process abstraction gave each program its own private CPU and memory. Files are different β€” they’re commonly shared among users and processes β€” so file systems need mechanisms to control that sharing. The classic one is the UNIX permission bits , the rwxrwxrwx you see in ls -l:

prompt> ls -l foo.txt
-rw-r--r-- 1 remzi wheel 0 Aug 24 16:29 foo.txt

The first character is the file type (- regular, d directory, l symlink). The next nine are three groups of read / write / execute β€” for the owner, the group, and other (everyone else). You change them with chmod, whose octal digits add read = 4, write = 2, execute = 1:

Reading rwxrwxrwx, and what chmod 600 does. Each group is a 3-bit octal digit (r=4, w=2, x=1).
type-ownerrw-6groupr--4otherr--4octalowner rw Β· group r Β· other r β†’ 644

1-rw-r--r-- (chmod 644)

Owner can read and write (rw- = 4+2 = 6); group can only read (r-- = 4); other can only read (r-- = 4). So the mode is 644.

step 1 / 2

The execute bit is special. On a regular file it decides whether the file can be run as a program; on a directory it instead grants the right to enter (cd into) and traverse it.

Aside: Superuser For File Systems

Who may override permissions to administer the system? On local file systems the answer is usually a superuser (root) who can access every file regardless of its bits. That power is also an inherent security risk: impersonate the superuser and you own everything.

Permission bits are coarse β€” just owner/group/other. Some systems (e.g. the distributed file system AFS) add an access control list (ACL): a precise, per-directory list of exactly which users have which rights (read, write, lookup, insert, delete, administer, lock) β€” far more expressive than three groupings.

Tip: Be Wary Of TOCTTOU

Time-Of-Check-To-Time-Of-Use: if there’s a gap between checking a condition and acting on it, an attacker can change things in between. A classic case: a root mail server calls lstat() to verify your inbox is a normal file, then appends to it β€” but between the check and the write you rename() the inbox to a symlink pointing at /etc/passwd, tricking the server into writing there. There’s no easy general fix; a good rule is to minimize code running with high privilege.

Check yourself: soft links and permissions

1.How does a symbolic link differ structurally from a hard link?

2.You do `ln -s file file2`, then `rm file`. What happens to file2?

3.Which is true about the LIMITS of hard vs symbolic links?

4.In -rw-r--r--, what do the nine permission characters mean?

5.What does `chmod 600 foo.txt` set, given r=4, w=2, x=1?

6.How do access control lists (ACLs) improve on classic permission bits?

6 questions