File Write Permission Rules

[Guy Harris]

(Corrected version of previous posting; in S5 releases with mandatory
locking, it's the set-GID bit that represents the "mandatory locking"
bit, not the sticky bit.)

>But with 4.3BSD(?) came the sticky bit for directories.

Yup.  (Actually, I thought I'd remembered it appearing in some 2.xBSD
release at one point, but I think somebody more closely connected with
those releases said it wasn't there.)

>Apparently someone somewhere noticed an unused bit in the mode word
>for directories. (With SunOS 4.x, I understand, you can even make
>directories setuid or setgid)

SetGID, yes.  SetUID, well, you may be able to turn the bit on, but it
doesn't do anything.  Turning the set-GID bit causes files (and
directories) created in that directory to have the group owner of the
directory, rather than the effective GID of the process that created
them, as their group owner; by default, unless the file system was
mounted with the "grpid" option, newly-created files have the effective
GID of the process that created them as their group owner.  (This was
done in order to permit both the old "use the effective GID" semantics
for the benefit of any programs from S5 or whatever that depend on it,
and the use of the new 4.2BSD-style "use the parent directory's group
owner" semantics, which are more convenient.  I think S5R4 will have the
same mechanism.)

In later S5 releases, the setGID bit is used for yet another purpose
other than rendering executable files set-GID; if the file is
non-executable, and the sticky bit is set, it means "record locks on
this file are mandatory", which means that a read lock on a region will
block "write"s to a region that overlaps that region, and a write lock
on a region will block "read"s or "write"s to a region that overlaps
that region.