• Choose a category
• All
• Classic-Fiction

/usr/include/bsd/sys/ufs/../param.h

resolves to

/usr/include/param.h

not to

/usr/include/bsd/sys/param.h

It is a common mistake to think that the first argument to ln -s has something to do with your current working directory. It is not resolved as a filename by ln; it’s simply used verbatim as the target of the symbolic link.

5.5 FILE ATTRIBUTES

Every file has a set of nine permission bits that control who can read, write, and execute the contents of the file. Together with three other bits that affect the operation of executable programs, these bits constitute the file’s “mode.” The twelve mode bits are stored together with four bits of file-type information in a 16-bit word.

The four file-type bits are set when the file is created and can’t be changed, but the twelve mode bits can be modified by the file’s owner or the superuser using the chmod (change mode) command. Use ls to inspect the values of these bits. An example is given on page 71.

The setuid and setgid bits

The bits with octal values 4000 and 2000 are the setuid and setgid bits. These bits allow programs to access files and processes that would otherwise be off-limits to the user that runs them. The setuid/setgid mechanism for executables is described on page 38.

When set on a directory, the setgid bit causes newly created files within the directory to take on the group ownership of the directory rather than the default group of the user that created the file. This convention makes it easier to share a directory of files among several users, as long as they all belong to a common group. Check your system before relying on this feature, since not all versions of UNIX provide it (though our example systems all do). This interpretation of the setgid bit is unrelated to its meaning when set on an executable file, but there is never any ambiguity as to which meaning is appropriate.

A few systems allow the setgid bit to be set on nonexecutable plain files to request special locking behavior when the file is opened.

The sticky bit

The bit with octal value 1000 is called the sticky bit. The sticky bit is an example of UNIX outgrowing something but not being able to keep it from tagging along anyway. Small-memory systems like the PDP-11/70s where UNIX spent its preteen years needed some programs to stay in memory or on the swap device continuously. The sticky bit was very important then. In today’s world of $25 memory modules and fast disk drives, the sticky bit on an executable is obsolete and modern kernels silently ignore it.

If the sticky bit is set on a directory, most versions of UNIX (including our example OSes) don’t allow you to delete or rename a file unless you are the owner of the directory, the owner of the file, or the superuser. Having write permission on the directory is not enough. This convention is an attempt to make directories like /tmp a little more private and secure.

Solaris and HP-UX are slightly less stringent in their handling of sticky directories: you can delete a file in a sticky directory if you have write permission on it, even if you aren’t the owner. This actually makes a lot of sense, though it makes little practical difference.

The permission bits

The nine permission bits are used to determine what operations may be performed on a file, and by whom. UNIX does not allow permissions to be set on a per-user basis.4 Instead, there are sets of permissions for the owner of the file, the group owners of the file, and everyone else. Each set has three bits: a read bit, a write bit, and an execute bit.

It’s convenient to discuss file permissions in terms of octal (base 8) numbers, because each digit of an octal number represents 3 bits and there are 3 bits in each group of permission bits. The topmost three bits (with octal values of 400, 200, and 100) control access for the owner. The second three (40, 20, and 10) control access for the group. The last three (4, 2, and 1) control access for everyone else (“the world”). In each triplet,