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.
39.15 Symbolic Links
A symbolic link symbolic link A soft link: a distinct file type whose data is the pathname of another file (ln -s). Unlike a hard link it can cross file systems and point to directories, but if the target is removed it becomes a dangling reference (points to a nonexistent path). Its size equals the length of the stored pathname.
defined in ch. 39 β open in glossary
(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.
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").
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 link (ln) | symbolic link (ln -s) | |
|---|---|---|
| What it is | another directory entry pointing at the same inode | a separate file (a third type) whose data is a pathname |
| Copies data? | no | no |
| Own inode / file type? | no β shares the target's inode | yes β its own little file |
| Size | (same file) | length of the stored pathname |
| Cross file systems? | no | yes |
| Link to a directory? | no | yes |
| If the target is removed? | file survives | dangling reference |
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 permission bits The classic UNIX access control: nine bits shown as rwxrwxrwx giving read/write/execute for owner, group, and other. Changed with chmod. For a regular file, execute means runnable; for a directory, execute allows cd/traversal into it. A coarser model than access control lists.
defined in ch. 39 β open in glossary
, 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:
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.
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 superuser The administrative user (root) who can control any process and run powerful commands; use sparingly. defined in ch. 5 β open in glossary (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 access control list An ACL: a more general, precise way than permission bits to say exactly who may access a resource and how, used by systems like AFS (per-directory). Where permission bits offer only owner/group/other, an ACL can list specific users and rights (read, write, lookup, insert, delete, administer, lock). defined in ch. 39 β open in glossary (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 callslstat() 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?