> FWIW, I believe the third bullet in particular (currently missing from
> Linux) makes the feature a *lot* more useful. Having the sticky bit tie
> delete permissions to write permissions allows processes with different
> UIDs to use /tmp and /var/tmp with more overall security. Think of
> cooperating processes where not all of them actually need a particular UID
> or a privileged UID. In this case, SVr4 "sticky dir" semantics
> allow/encourage least-privilege design. Linux semantics currently don't.
Since 4BSD derivatives do not have this semantics it's pointless
- you will get a non-portable code that can be very hard to fix. IOW,
anything that relies on such property is broken by design.
> If you already can write to a file, being able to actually delete it isn't
> likely to create an *additional* security hole. Exception: If the file's
> existence is used merely as a semaphore and the contents ignored -- but
> then there is the obvious possibility of not making the file writable by
> the world when it is created.
The same reasoning shows that in 99% of cases you simply will not
need this feature. Playing with permissions semantics (_removing_
restrictions at that) just because someday somebody might want to write
(unspecified) non-portable code... Yuck.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/