On Jul 31,  1:50pm, Lon Willett wrote:
} Subject: Re: Symlink ownership
}     > However, I think that ditching the new semantics is a good idea,
}     > UNLESS someone actually comes up with a reasonable reason why
}     > they're needed (e.g, some braindead OS with potential POSIX
}     > aspirations can't handle the traditional format of symlinks...)
} 
} The real reason to use the POSIX semantics is to avoid having to make
} tar/cpio/every-other-archiver understand symlink ownership; and to avoid
} having to implement "lchown" and l-every-other-inode-manipulating-syscall,
} and then having to make NFS deal with them.  And then you'll still have
} problems with older NFS servers that don't give you "lchown" or don't
} support it in their underlying FS.

Well, the tar and cpio archive formats already have a slot in which to stick
the uid, etc. for symlinks, so it seems to me that when creating the
archives a strictly POSIX archiver would be more complicated because it has
to do something special for symlinks rather than just copying the st_uid
value it got from lstat() like it does for plain files, directories, etc.
When restoring from the archive, symlinks are special cased anyway, since
you don't want to chown() them.  Calling lchown() instead of doing nothing
doesn't sound like too much of a burden.

NFS doesn't require an lchown() RPC, since the client will just call
the chown() RPC with the filehandle of the symlink.  The only special
requirement is that both the client and the server support symlink
ownership.  When the client chown()'s a symlink, it will follow the
link and send the chown() RPC to the server with the filehandle of the
symlink's target.

} Again, perhaps I've missed something in this thread, but I don't see
} what having symlink ownership buys you that is worth the extra
} complexity that must be added to every program that attempts to grok the
} filesystem.

Well given that they already have to know that they have to call lstat() ...
Seriously, about the only programs affected are those that attempt to
duplicate an existing filesystem, including timestamps, ownership, etc.,
which is pretty much limited to the archivers tar, cpio, and dump/restore.

} The only real reason I've heard is disk quotas. But since
} giving someone write access to a file or directory you own (sticky-bit
} or not) automatically lets them do some things that count against your
} quota and not theirs, I don't see this as significant.

Because the symlink contents can be pretty fair sized, it's faster to
gobble up someone else's quota that way.  Assuming short files you can
even:
	ln -s "`cat ~/myfile1`" /tmp/myfile1
	ln -s "`cat ~/myfile2`" /tmp/myfile2
Who says symlinks need to point to files ;-)

} Assuming
} non-malicious behaviour, how many symlinks are created in directories
} other by its owner?  Not many, I'll bet.

It depends on your environment.  Here we've got a lot of group writable
directories for groups of users working on common projects.

} And, as I've mentioned,
} malicious behaviour is possible anyway, regardless of the way symlinks
} are handled.

In our environment, malicious behavior is not a problem, but occasional
accidents are.  Having used systems which have symlink ownership and
those that don't, I much prefer the systems that have symlink ownership
and timestamps.  We have a significant number of Apollo DomainOS boxes
here on which symlinks appear to have the same ownership and timestamps
as their parent directories.  We have an outside vendor provided
application that fiddles around a lot with symlinks.  I find it incredibly
frustrating that when something breaks I can't do an "ls -l" on the
directory to find when the links were changed and who did it.  I really,
really wish I had some way of knowing that I should ask Joe (or whoever)
what he was doing yesterday at 3:35 that caused the problem.  Lacking
this information, I have no way of finding out who the responsible party
is so that I can take steps to prevent the recurrence of this problem.

} To me, the KISS principle seems to dictate that the POSIX semantics are
} a good thing.

Putting aside the semantics for a moment, I don't think the scheme for
putting symlink contents into the directory entry (and it sounds like
the vendors that use this scheme are the culprits who pushed POSIX
toward the semantics under discussion) simplifies things a bit.
For instance, lstat() has to treat symlinks significantly differently
than regular files, directories, etc.  Also, an NFS server now needs
two schemes for generating file handles.  One scheme for plain files,
directories, etc., and another capable of handling an arbitrary number
of symlinks contained within a given directory.  These file handles must
not change as other symlinks or other directory entries are added or
deleted.  The server code for the readlink() RPC all the sudden looks a
lot different than read().

Since the implementation sounds so gross, I'd say there is no reason
to not keep symlinks inode based.  Given that, in what way would it
conflict with POSIX to give owners to symlinks in NetBSD?  Since
POSIX says that symlinks don't have owners, I would think that
POSIX would say that applications that want to be portable to all
POSIX systems must ignore the value of st_uid for symlinks.  If so,
then it shouldn't matter to these applications what value that NetBSD
puts in there (even the uid of the creator of the symlink!).  Or did
POSIX do something totally braindead and say that these applications
can look at st_uid for symlinks as well as dictate its expected value?

Ideally, I'd like to see tar and friends save the owner of the symlink
in the archive on those systems that have owned symlinks, and the owner
of the containing directory if the symlinks are ownerless.  An ownerless
archive restored on a filesystem with owned symlinks would create the
symlinks with reasonable owners.  An archive with owned symlinks
restored on an ownerless symlink filesystem would only lose the symlink
ownership information.  On a roundtrip, the original ownership woundn't
be restored, but gee-whiz, this is still a lot better than what happens
if you try to try to do the same thing with a filesystem containing long
file names and a filesystem that only supports short names.  Hmm, maybe
I shouldn't have mentioned that.  Next thing I know, POSIX will mandate
that no POSIX compliant system can support file names longer than 14
characters ;-)

			---  Truck