| set -e
| tty defs
| tty chars
| using siginfo
| line charset
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
The sticky bit in
/tmp is well known.
But then I heard of more special meanings and became curious.
By the way: did you know that the setuid bit is patented? Pt. no 4135240.
Fortunately, by Dennis M. Ritchie himself.
See f.i. the USPTO search and search for this number. Update: see google patents/US4135240.
2015-05-01 (see recent changes)
set uid (without execute by user)
set gid (without execute by group)
- [SVR4 (SVID3) , SunOS 4, SunOS 5, HP-UX 9]:
Mandatory file locking in connection with
See also "available implementations" in
Locking for Linux (
- 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:
NetBSD up to 4.0:
chmod(2), but not
- 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:
- OSF1/v4 ff.:
- OpenServer 5.0.6 / 6.0.0:
vi, ls, sh
In a related discussion following
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
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:
- [HP-UX 9] to create context dependent files,
Implemented with a hidden directory containing the actual,
respective entries for different unix nodes.
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
/etc/inittab, the system "node1" will see
other systems will see
# ls /etc/inittab+ (see the content of the directory)
# ls -lHd /etc/ (see the hidden directory itself)
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
- 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
- [4.3BSD, SVID4] widely known appliance in
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.