I have one question:

> There is still a possibility -- especially in shared writable
> directories, or if the user is foolish enough to have a symlink into
> a shared writable directory -- of symlink race attacks.  This is not
> specific to setuid or natively root programs, nor is it even
> specific to the device/socket/pipe `issue'.  One solution to it is
> O_NOFOLLOW, which I believe at least one other system is already
> using.

What specific class of symlink race does O_NOFOLLOW solve, and how
does a program know when it should use it?  O_EXCL is good enough for
creating new files.  The only situation where I can imagine wanting to
use O_NOFOLLOW is when appending to a log file known to be located in
/tmp or /var/tmp, and I'm not sure whether that's important enough to
merit a new kernel extension.  (Being secure is always important, but
being able to write a program which appends to logs in /tmp is not
necessarily important.)