Special Usage of Permission Bits

Special Usage (overloading) of Permission Bits on various Unix flavours

apart from read/write/execute. So it's about:

S_ISUID   04000 set user ID on execution
S_ISGID   02000 set group ID on execution
S_ISVTX   01000 sticky bit

1. Files

set uid (without execute by user)

(still to be discovered)

set gid (without execute by group)

[SVR4 (SVID3) , SunOS 4, SunOS 5, HP-UX 9]:
Mandatory file locking in connection with fcntl(), see chmod(2).
See also "available implementations" in Mandatory File Locking for Linux (src/linux/mandatory.txt, '96).

sticky bit

the widely known meaning for executables,
<sys/stat.h> on 7th edition: "S_ISVTX: save text image after execution"
- [7th edition, System III, 4.3BSD-Reno] Only to be set by privileged users.
  Usually not implemented anymore after the following releases
  due to improved virtual memory management, that is, not only swapping but paging:
  - 4.3BSD-Reno (<3B6EEE3C.10P11YWI7@bigfoot.de>)
  - SVR3? The UNIX FAQ mentions SVR3 for introducing demand paging, Wikipedia mentions SVR2.
- However, a few later systems still document it with its original meaning, e.g.,
  OpenBSD up to 3.4: sticky(8), HP-UX 11: chmod(2). NetBSD up to 4.0: chmod(2), but not sticky(7).
- On HP-UX 11, all ex/vi hardlinks have this bit set.
  Apparently, this bit is still used for local paging of executables located on an NFS. See the HP-UX FAQ.
- and there are systems where the bit survived but seems to be inactive:
  - IRIX 5.3, 6.5.16: ex
  - OSF1/v4 ff.: ex/vi (hardlinks)
  - OpenServer 5.0.6 / 6.0.0: vi, ls, sh
    In a related discussion following <f6s46k$dsu$1@news.ya.com>, comp.unix.sco.misc,
    Bela Lubkin tells that he searched the source of an early OSR5 without finding any effective remains.
[HP-UX 11] on symbolic links:
transition links are created with the almost undocumented lchmod(2).
Purpose: to ease transition to new SVR4 FS layout.
See the HP-UX FAQ.
[IRIX 5.3, 6.5.16] dynamic loading of elf executables:
The read only address space of the old process is made available
to the loader in the new process (possible speed-up)
[SunOS 3 and 4] on regular, non-executable files:
system page cache is not used; for example for swap files of diskless clients,
so that swapping doesn't flush more valuable data in the page cache.
Still documented on SunOS 5, sticky(5), but unimplemented.
Implementation on SunOS 4: sys/ufs/ufs_vfsops.c, ufs_vget(), VISSWAP

2. Directories

set uid

[HP-UX 9] to create context dependent files, "S_CDF" for chmod(2):
Implemented with a hidden directory containing the actual, respective entries for different unix nodes.
See also cdf(4), context(5).
Intended as support for diskless workstations, this is not supported anymore since HP-UX 10, in favour of NFS.
An example, providing context dependent versions for the file /etc/inittab:
```
	# mkdir /etc/inittab
	# chmod +H /etc/inittab
	# touch /etc/inittab+/node1 /etc/inittab+/default 
```
When accessing /etc/inittab, the system "node1" will see /etc/inittab+/node1, other systems will see /etc/inittab+/default.
```
	# ls /etc/inittab+       (see the content of the directory)
	node1
	default
	# ls -lHd /etc/          (see the hidden directory itself)
	[...]
	/etc/inittab+ 
```
The flag H makes the directory inittab visible and (-F is implied) appends a "+" to the name.
Numerous other utilities also implement such a flag (find, tar, pax, pwd, ...)
[FreeBSD X] (user-)ownership of new directory entries.
Used to "reduce support calls for file servers". It's optionally available with the "kernel option "SUIDDIR"
[SCO OpenServer 5] John DuBois reports: On HTFS filesystems with file versioning ("undelete") enabled, the setuid bit on a directory determines whether file versioning is enabled for that particular directory. If it is, files in that directory that are removed or opened with O_TRUNC are actually moved to a versioned name, and versioned names are hidden from the view given by readdir(). Newly created directories inherit setuid from parent directories.

set gid

widely known meaning (group-)ownership of new directory entries:
New entries will inherit the group id from the directory.
This is is not required on BSDs, where this behaviour is default (introduced with 4.4BSD-alpha)
and where it is usually documented in open(2).

sticky bit

[4.3BSD, SVID4] widely known appliance in /tmp:
directory entries can only be removed/renamed if the user (EUID) owns the entry or the directory or if the file is writable for him.

<http://www.in-ulm.de/~mascheck/various/permissions/>