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