On Tue, 1 May 2001, Giles Lean wrote:

# Greywolf wrote:
# > This is a Feature of NetBSD -- a point where value is actually added.
# > IIRC, code was put in where we treat symlink permissions differently
# > than standard file permissions.  see symlink(7).
#
# ... and that manual page says (on a 1.5 system):
[snip]
#
# So by my reading 'chmod file' should also covered by this case, but
# 'chmod -R directory' would not be.  There are exceptions listed later
# in the manual page, but chmod is not one of them.
#
# Also, chown and chgrp get special mention as commands that were
# changed to follow symbolic links in 4.4BSD.  Presumably this change
# was for consistency with this rule.  Was chmod overlooked?

I was actually under the influence of something which was telling me
that chmod/chgrp/chown should all be operating on the link, not the file.

...or was that a different discussion?  I thought we had implemented some
semantics which would actually take into account ownership and modes of
the symlink in reaching the final target such that it would be possible
to create links which could tunnel through directory permissions (in a
sane way, of course, inasmuch as symlinks are sane).  Hmmm, how'd I get
in this hole and what am I doing with this shovel...?

# chmod(1) is certainly implemented as if it is always traversing a file
# tree. Charles says that the current chmod(1) behaviour is documented.
# Is there more documentation that I've missed, or do I misunderstand
# what I've read?

I'm not even sure that I understand what I read after I glossed over
the symlink(7) page.  It's a bit twisty.

# (I still consider the *behaviour* wrong.  If it doesn't match the
# current documentation this is easier to argue though than if it does
# match the documentation, so the documentation issue is worth resolving
# first.)

It appears consistent to me.  Maybe I'm not bashing enough on it.

				--*greywolf;
--
*BSD: Are you old enough to run it?