>> lstat() is not necessary if you just define stat() to not follow
>> links, and then let people readlink() the link if [...]
> I think it's way too late for this change in a UNIX/POSIX system....

Oh yes.  I'm not suggesting this be done, just pointing out that even
the lstat()/stat() is not strictly necessary.

>> By why aren't they?  It would make perfect sense, to me, for the r
>> permission to control who can readlink() the link and x to control
>> who can follow it during a normal path walk.  (No reasonable meaning
>> for the 07222 bits comes to mind.)
> I thik I like this....

I have implemented the 0555 bits as described above; it turns out to be
extremely simple to do.  (To save adding lchown() and lchmod(), I made
chown() and chmod() not follow terminal links.  If it were done "for
real", it may be better to add lchown() and lchmod() instead.)

Since I wrote the quoted text above, a meaning has come to mind for the
0222 bits: if the symlink is writable by someone, then that user can
replace the link in-situ by doing a symlink() call, without having to
unlink() it first.  I'm not sure whether I think this is a good idea.
I have not implemented it.

For the 06000 bits, I have a somewhat off-the-wall idea: if the symlink
is set-uid, then the remainder of the path walk (but not the operation
at the end of it!) is performed as if by the owner of the symlink.
Ditto for set-gid and group.  ("Remainder" at least up until another
set-id symlink is encountered, of course.)

This leaves the sticky bit.  What could sticky mean for symlinks? :-)

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu