Understanding Linux directory permissions reasoning
Execute bit: The execute bit is needed to traverse a directory. Permission to read a directory is controlled by the read bit.
See this shell dialogue for an example of this difference:
As root:
# find foo/ -lsdrwxr-xr-- 3 root root 4096 Apr 27 12:57 foo/drwxr-xr-x 2 root root 4096 Apr 27 12:57 foo/bar-rw-r--r-- 1 root root 0 Apr 27 12:57 foo/bar/file
as user:
$ ls foo/bar$ find foo/ -lsdrwxr-xr-- 3 root root 4096 Apr 27 12:57 foo/find: foo/: Permission denied$
The usual usage is the other way round though: removing read permissions but allowing traversal, e.g. to allow a web server into ~/public_html but not letting it do the default index listing by setting --x.
Sticky bit: This was invented exactly to avoid the default rules about deletion within a directory so /tmp works. /tmp might reside on a different volume than /home and/or be governed by different quotas.
The FHS codifies /tmp "for programs that require temporary files" while "[they] must not assume that any files or directories in /tmp are preserved between invocations".
Personally, I consider /tmp to be legacy from the heathen days when vi globals.h && make install was considered an installation procedure. Nowadays programs should honour $TMPDIR, which should point to a user-private system-managed directory, which should be cleaned at least on reboot. Even standardised functions like tmpfile(3) do not prescribe the actual path. Although there seem to be important compatibility and security concerns speaking for /tmp. Note though, that the last mail is from 1999, so things might have change since then.
Just stumbled across this because it's got a high Google search rating. The execute-bit issue hasn't really been answered, so...
If the execute bit isn't set on a directory, then it's not "traversable", which means that shells and file browsers should be designed to disallow you from setting that directory as current, although that feature can't be enforced by the file-system itself. What the file-system does disallow on a no-execute directory is any information other than the filename of the contained files -- so no datestamps or file-permissions of those files, and no reading of those files even if they have read set.
The most common use of the sticky bit today is on directories, where, when set, items inside the directory can be renamed or deleted only by the item's owner, the directory's owner, or the superuser; without the sticky bit set, any user with write and execute permissions for the directory can rename or delete contained files, regardless of owner. Typically this is set on the /tmp directory to prevent ordinary users from deleting or moving other users' files. This feature was introduced in 4.3BSD in 1986 and today it is found in most modern Unix systems.
In addition, Solaris (as of Solaris 2.5) defines special behavior when the sticky bit is set on non-executable files: those files, when accessed, will not be cached by the kernel. This is usually set on swap files to prevent access on the file from flushing more important data from the system cache. It is also used occasionally for benchmarking tests.
The sticky bit is also set by the automounter to indicate that a file has not been mounted yet. This allows programs like ls to ignore unmounted remote files.