> 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?
> 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
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. 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/