Classic Shell Scripting - Arnold Robbins [243]
Finally, restore read access, but not execute access, and repeat the experiment:
$ chmod a+r test
Add directory read access for all
$ ls -lFd test
Show the directory permissions
drw-r--r-- 2 jones devel 512 Jul 31 13:34 test/
$ ls -l test
Try to list the directory contents
ls: test/the-file: Permission denied
total 0
$ ls -l test/the-file
Try to list the file
ls: test/the-file: Permission denied
$ cd test
Try to change to the directory
test: Permission denied.
Lack of execute access on the directory has blocked attempts to see its contents, or to make it the current working directory.
When the sticky bit is set on a directory, files contained therein can be removed only by their owner, or by the owner of the directory. This feature is often used for publicly writable directories—notably, /tmp, /var/tmp (formerly called /usr/tmp), and incoming mail directories—to prevent users from deleting files that do not belong to them.
On some systems, when the set-group-ID bit is set on a directory, the group ID of newly created files is set to the group of the directory, rather than to the group of their owner. Regrettably, this permission bit is not handled the same on all systems. On some, its behavior depends on how the filesystem is mounted, so you should check the manual pages for the mount command for the details on your system. The set-group-ID bit is useful when several users share write access to a directory for a collaborative project. They are then given membership in a special group created for that project, and the group of the project directory is set to that group.
Some systems use a combination of the set-group-ID bit being set and the group-execute bit being clear to request mandatory locking, a messy topic that we do not treat in this book.
* * *
Directory Read and Execute Permissions
Why is there a distinction between reading the directory, and passing through it to a subdirectory? The answer is simple: it makes it possible for a file subtree to be visible even though its parent directories are not. A common example today is a user's web tree. The home directory might typically have permissions rwx--x--x to prevent group and other from listing its contents, or examining its files, but the web tree starting at, say, $HOME/public_html, including its subdirectories, would be given access rwxr-xr-x, and files within it would have at least rw-r--r-- permissions.
As another example, suppose that, for security reasons, a system manager wants to read-protect an entire file subtree that was not previously protected. All that needs to be done is to remove read and execute access for the single directory at the root of the subtree, with chmod a-rx dirname: all files below that point become instantly inaccessible to new open attempts (already-open files are not affected), even though their individual permissions might otherwise allow access.
* * *
* * *
Tip
Some Unix systems support a feature called access control lists (ACLs). These provide finer control of access permissions so that specific users or groups can be assigned nondefault permissions. Unfortunately, the tools for setting and displaying ACLs vary widely between systems, making ACLs of little use in heterogeneous environments, and too messy for further discussion in this book. If you want to learn more about them, try man -k acl or man -k 'access control list' to identify the relevant commands on your system.
* * *
File Timestamps
The inode entry for a Unix file contains three important timestamps: access time, inode-change time, and modification time. These times are normally measured in seconds since the epoch,[22] which for Unix systems is 00:00:00 UTC, January 1, 1970, although some Unix implementations offer finer timer granularity. Measuring in UTC [23] (Coordinated Universal Time, formerly Greenwich Mean Time, GMT) means that the timestamps are independent of the local time zone.
The access time is updated by several system calls, including those that read and write files.
The inode-change