Cough! There are levels of trust, you know. If someone does consume my
quota, all I need to do is find out who did it (if I'm a mere mortal,
I may have to ask my sysadmin for help), and then walk over to the
comedian and threaten to remove their gonads through their throat.
Giving everyone the root password is entirely different. I wouldn't be
able to store semi-sensitive information on said system. And the
system would become a dogs breakfast of ad-hockery (too many cooks
spoil the broth).
> But the fact that we don't have a working revoke() is the more
> important problem. Forget local attacks. What about telnet to port
> 80, type GET /~user/bigassgif.gif, and hit ^]^Z so the transfer will
> never finish? rm needs some teeth for such situations.
Adding teeth isn't as simple as you'd think. Always doing a revoke(2)
isn't a solution, becuase more often than not, you just want to
schedule a file for deletion (i.e. the original definition of
unlink(2)), because there might be legitimate programmes still holding
the file open which you don't want to screw with.
So if you first do a regular unlink(2) (since that is the general
case), even if someone has an open FD, it's too late, because you
don't have a path to the file anymore.
So you see, there is no easy choice. Either you shoot first and ask
questions later, in which case you have a bunch of innocent
bystanders, or you tread carefully, in which case some undesirables
get away with it.
BUT NOTE: there is no major damage done. A reboot will fix all
references to open fds, and a simple script will clean up hard
links. We're really talking about minor irritations, like flies on
your back.
Personally, I'd rather swat them from time to time (with some getting
through my defences), than coat myself with DDT.
Regards,
Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca
-
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/