> On Wed, 1 Dec 1999, Peter J. Braam wrote:
>
> > 2. Hard links across directories are not permitted. Jan explained that
> > security is an issue here.
> >
> > I think there is wrong thinking in the way Unix does things normally and
> > the security argument goes away when the following reasoning is followed.
> >
> > Unix pretends a hard link is merely a modification of a directory. Of
> > course it does add a name to new directory but it also subtly alters the
> > attributes of the file in question, since it raises the file's link count.
>
> Effectively open does the same wrt keeping file alive. So?
I have said nothing about open - just about link.
>
> > A perfectly acceptable fix for the (many) problems with link are to permit
> > links only if:
> >
> > - the process can write to the target directory
> > - process can modify the attributes of the file it wants to link
>
Again, let's talk about link, not about open.
> Umhm. Wonderful. So open(2) is permitted only if we can modify the
> attributes of file? I don't think so. And that provides the same thing -
> you can use /proc/<pid>/fd/<fd> as a link.
>
> > This would work fine in Coda and also solves the problem that arise from
> > people keeping hardlinks to insecure suid programs, since they normally
> > cannot change their attributes.
>
> Or people with insecure suid programs can call truncate() before unlink().
> Problem solved.
>
> > Would Aegis be happy with that? Would Linux in general?
>
> Aegis - maybe. Linux in general? IMNSHO it seriously breaks normal UNIX
> semantics.
OK, how serious? Does it outweigh the benefits.
If it remains CODA deficiency - fine, but if you want to make
> this behaviour standard on normal filesystems... No, thanks. And I
> suspect that you'll hear the same from *BSD folks.
>
