Understanding Linux directory permissions reasoning

Question

Hi I have 2 questions regarding linux directory permissions which I do not understand.

I removed the execute flag from a folder named Documents. After that I cannot use cd on it but I still can do "ls Documents" from the parent directory and it still lists me the files in the Documents directory. I though the missing x-flag denies reading this directory?

Then I want to know for why the sticky bit on directories was invented. I've heard it was used so that users cannot delete temp-files creates by other users. But this IMO violates the rule that for deletion of files we just need rights for this directory. Why not simply give each user a separate /tmp/ directory instead of introducing exceptions in the rule system? I know what the flag does, but I want to know the reasoning on why is was invented.

Answer 1

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/ -ls
drwxr-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/ -ls
drwxr-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. Not though, that the last mail is from 1999, so things might have change since then.

Answer 2

Sticky bit

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.