On Tue, 29 Oct 2002, der Mouse wrote:

# >> Well, permissions are then set on the symbolic link, not the files
# >> they point to
# > No, no.
# > Normally, symlinks don't have permissions.
#
# For what value of "normally"?  Symlinks have had permissions
# approximately forever (certainly every system I've used that had
# symlinks, since...when did symlinks show up? I can't recall whether
# they were in 4.1c, 4.2, or what).  Those permissions have been ignored
# (and approximately impossible to change) on most systems, but they've
# been there.

Actually, IIRC, symlinks permissions defaulted to 777, did they not?
I seem to remember them doing that (and, of course, wondering why I
couldn't change them.)

(of course, I also seem to remember everyone in the computer lab group
having a $HOME/ext directory comprised of symlinks to all the stuff
in everyone else's $HOME/bin...and wondering why ls -F ran so slow :)).

#  (You can tell by using ln -s with varying umask settings
# and noticing that the resulting values are remembered.)  I've never
# understood the rationale for ignoring symlinks' mode bits, nor,
# especially, for making symlinks transparent to chmod(2).

I think by default making them transparent was probably the best course
of action at the time, since the only projected use for them was to
cross device boundaries or to act as what is termed in Windows parlance
as "shortcuts" (although I note they still don't have it right).

i.e. "lack of foresight" comes to mind.

# There are doubtless some reimplementations of symlinks that did away
# with their permissions.  I don't consider this as invalidating the
# point that they've been there in FFS, where symlinks were brought in,
# all along.
#
# > -h      If file is symbolic link, the mode of the link is changed.
#
# > This is a NetBSD extension.
#
# I don't think it's all that NetBSD-specific (ie, I don't think it's
# fair to call it a *NetBSD* extension).  Other systems have settable
# symlink modes; the only specific example that comes to mind is OSF/1,
# but I've never gone looking for others.

Solaris and AIX specifically state that permissions on symbolic links
are ignored; seeing as HP-UX isn't exactly a leader in the UNIX world,
I wouldn't be surprised to see them ignored there, too.

Now, what amazed me at the example given which started this thread
is that neither the file's permissions _nor those of the symlink_
were changed, and that is MOST definitely broken (NIST-PCTS would have
agreed with this statement).

But I see it's been fixed already, so...

Hmmmm.  It's been a while since I've seen a PCTS or even a POSIX draft.
I wonder if I should write one (PCTS, that is)...or does one exist for
free, already?

[It'd be useless to anyone except Standards pundits.]

# /~\ The ASCII				der Mouse
# \ / Ribbon Campaign
#  X  Against HTML	       mouse@rodents.montreal.qc.ca
# / \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Side tangent on modes:  Do we do the sticky-bit overload that Solaris
does in which a non-executable file with the sticky bit set will never
have its blocks in the cache (for, e.g. NFS swap)?

If so, it's not reflected anywhere in the documentation; if not, well,
it is overload, but it strikes me that it wouldn't be an altogether
_bad_ idea...

				--*greywolf;
--
NetBSD: Twice the Bits-Clean of other Leading OSes.