> On Thu, 2 Dec 1999, Alexander Viro wrote:
>
> >Don't bring the policy question into the kernel. If you want to kill the
> >contents of inode - unlink() is _not_ a way to go. truncate() is.
>
> What have unlink() or truncate() to do with this issue? The only system
> call we are talking about is _link_(2).
>
> Even supposing you can undo after 1 pico second the effect of the link(2),
> for one pico second the system stayed in a state I don't like.
Excuse me? I'm saying that you can emulate link() with open(). And the
workaround being the same - cat /dev/null > file_to_delete. Look:
a) if you have file visible to attacker - he doesn't need link(),
he can use the original reference until you remove it.
b) if you are removing the reference, but not the contents - you
are unsafe even if attacker didn't call link() at all. He might say
exec 17<file_you_were_going_to_delete and use /dev/fd/17 afterwards.
c) taking system single-user is slightly more drastic measure than
using cat. So even the "oh, I'll drop to single-user/reboot and his
processes will go away" doesn't cut it - it's _massive_ overkill. And if
you can do that - you have root and if there are extra links to the file
you'ld better (1) truncate it anyway, (2) spend a couple of minutes to
find other links, (3) look around in the attacker directories - he may
have more interesting things there and (4) LART the kiddie _hard_.
Again, until you've removed your link _other_ links do not matter.
And once you've removed it it will not be used to create new ones anyway.
I still don't see anything you could buy prohibiting link().
-
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/