#: From kstailey@owl.dol-esa.gov Thu Aug  3 15:02:36 1995
#: Posted-Date: Thu, 3 Aug 1995 18:00:29 -0400
#: Date: Thu, 3 Aug 1995 18:00:29 -0400
#: From: Kenneth Stailey <kstailey@owl.dol-esa.gov>
#: To: greywolf@tomcat.vas.viewlogic.com
#: Cc: mouse@Collatz.McRCIM.McGill.EDU, current-users@NetBSD.ORG
#: Subject: Re: Symlink ownership
#: 
#: > The problem is not the sticky directory -- that's worked *fine* until
#: > someone tried to muck with the symbolic link.
#: 
#: So this is *fine* behavior:
#: 
#: owl% cd /var/tmp
#: owl% ln /var/log/messages foo
#: owl% rm foo
#: override rw-r--r--  root/wheel for foo? y
#: rm: foo: Operation not permitted
#: 
#: That means I should want to create links that I can't remove.  Problem
#: is I don't want to be able to make things I can't remove.  Maybe it's
#: *fine* for you, but it's *broken* to me.

Sigh.

#define CODE_BLOAT
Perhaps ln(1) should issue a warning/confirmation if you're trying to
hard-link to a target you don't own in a sticky directory?
#undef CODE_BLOAT

Never mind, of course, that mv used to use "link(old,new); unlink(old);"
before rename() came along.  Not that it makes a difference, since you
can't rename() something you can't unlink()...

The thing I'm getting at is that, with hard links and sticky directories,
you pays your money and takes your chances, as it goes.

There's no real win here; if we muck up the directory structure, we pay
for it in convolution and some degree of a performance hit.  If we
get rid of sticky directories, we lose something there as well.

I guess we really can't have both without seriously clouding up existing
semantics.

In answer to your statement, though, *YES* the above behaviour is fine.
It does what it is supposed to do, which is why having symlinks inherit
the owner of the parent directory is NOT an acceptable solution.
Hard links act as one would expect them to; they were never meant to be
discernable from their original (witness my statement about "mv" above).

There is another way, but it would require some *serious* rethinking of
the way the inode is laid out.  You would not only need "owner", but "creator"
identification, and, if you were to take it even further, have a "st_ilink"/
"di_ilink" field in the inode which references the inode of the link during
a lookup.  But there again, there is a significant overhead in doing it this
way, since it's much easier to write an entry (name, inumber) into a directory.

This is quite possibly the thread that will not die (TTWND #2, I think).

#: 
#: ~Ken
#: 

					--*greywolf;