> > Effectively open does the same wrt keeping file alive. So?
>
> I have said nothing about open - just about link.
... and anything that relies on unlink() as mechanism to remove the file
contents is broken, so prohibiting link() alone will not change _anything_
security-wise. If you can kill processes of potential attacker you can
remove his links too. Moreover, there is a standard way to remove the file
contents and it's _not_ unlink(). It's cat /dev/null>foo (==truncate()).
Again, unlink() was never supposed to remove the file. None of the Unices
provide such semantics. So if somebody relies on that - he will lose. Big
way. Proposed change does not fix any security holes, it only gives false
sense of security. If you have a hostile environment and blindly rely on
rm to remove a file - you have a security problem on hands.
> > Aegis - maybe. Linux in general? IMNSHO it seriously breaks normal UNIX
> > semantics.
>
> OK, how serious? Does it outweigh the benefits.
What benefits? OK, we did that change. You have a suid binary foo and it's
broken. You are saying rm foo, just to discover local cracker abusing foo
two hours later. It is supposed to be a benefit?
The same applies to quota abuse. And unlike the link(), this scenario
doesn't rely on access to the same filesystem. If somebody wants to play
such games link() is the least of your problems - it's effect can be
completely reproduced with plain open(). exec 42</bar/foo and several
hours after that sh -c /dev/fd/42 will do the trick - fork() preserves
open descriptors.
-
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/