[copied and pasted, as I am not subscribed to this mailing list...]

> Symlink permissions do mean something on some systems, and not just as
> an additional mask applied to the linked-to objects.  In particular,
> since we're talking NetBSD, if the filesystem is mounted with "symperm"
> enabled, the read bit on a symlink controls use of readlink() on it and
> the execute bit controls whether it can be followed during a path walk.
> Neither one affects the read or execute permissions on the pointed-to
> object, if any.  (Logically speaking, the write bit should control
> replacing the link, eg with symlink(), but symlink() refuses to replace
> an existing link at all.)

Thanks a lot for this detailed explanation of symlink permissions.
Certainly I am learning *a lot* listening to the NetBSD mailing lists
and to people like you.  :-)

Ok, when a filesystem is mounted with the "symperm" option enabled symlink
permissions are, in some way, interpreted as permissions in directories.
It seems logical, indeed, as symlinks are not "files", from the users
point of view, but paths to files than can be followed when walking
through directories.

I never used the symperm option, perhaps it is useful enabling symperm
for /home... as I suppose that symlink permissions in the NetBSD
operating system directories are not carefully choosen to modify
its behaviour (it seems NetBSD symlinks are all 755 and owned by
root:wheel).

Of course, I was not refering to the pointed-to object but to the
symlink itself.  I certainly should write more carefully!

> > File permissions should be preserved and must never be changed by
> > file management tools.

> Well, except as part of the interface contract of the tools - for
> example, chmod's entire raison d'etre involves changing them.

Of course!  :-)

Indeed, I cannot think on a use for chmod that is not related with
changing permissions!  But I think that pax was not one of these
tools that should change permissions... ok, there are some exceptions:
tar without "-p" or when it is run by users other than a superuser.
But allowing a non privileged user to restore the setuid/setgid
bits for files not owned by him is, at least, a violation of the
interface contract, and a serious security concern.  :-)

Best regards,
Igor.