Messages in this thread | | | Date | Fri, 21 Jul 2000 05:41:16 -0400 (EDT) | From | "Mike A. Harris" <> | Subject | Re: TO HELL WITH IT THEN......(re: disk-destroyer.c) |
| |
On Fri, 21 Jul 2000, Vojtech Pavlik wrote:
>> Alright, actually, after having a cup of coffee (most of which ended up >> on my keyboard :( ), I fully agree with our poor misunderstood friend >> Andre. If something is providing access to something at a protocol level, >> it is its job to make sure that the protocol is not violated.... imagine a >> TCP/IP stack that let you send invalid packets, that wouldn't go over too >> well. > >Of course you can send invalid TCP/IP packets using the network stack in >Linux. You can send any packets.
An invalid TCP/IP packet however does not permanently destroy the ethernet card, no matter how badly it is screwed up. Nor does it fry anything else.
IMHO, if something violates a standard in some way in kernel, it should be fixed if for no other reason than that. If something is a potentially dangerous, and lesser used feature that is added to the kernel, it should be CONFIG_SOMETHING so that it isn't there if it isn't needed.
Forget all the other arguments about root can do this and that anyway. You're right, if root WANTS to destroy the hard disk, he sure can. He can kick the machine off the disk and pick it up and throw it out a 10 story window if he wants also. What about the case where root DOES NOT want to destroy the disk, and doesnt want something else to be able to do so easily either?
I think that Andre's idea is right on the money and have yet to see a single even remotely good argument against it. If the current behaviour violates a standard, then it should be fixed. Losing data is one thing, losing hardware is another. Any feature the kernel can give to make physical hardware destruction impossible or much more difficult is a MAJOR plus in my opinion. I think that our machines have all too much hardware in them that is software destroyable nowadays. The only thing that protects them right now is "security through obscurity" where the 1's and 0's of how to fuck up the hardware aren't widely known. Once it is known, I'll bet we start seeing nasty things happen. If linux can all out prevent this, that is great. If it can make it extra difficult, that is good too. If it prevents accidental cases where such destruction was initiated but not MEANT by a stray program for example, that is good as well.
The only thing I'm surprised by now is all the negative energy put forth for no real gain - against Andre's hard work. Why not spend time fixing other broken things instead? If everyone attacks every solution to every problem, then we get nowhere.
Of course, that is only my $0.03 (The US dollar is worth $1.50 here now)...
TTYL
-- Mike A. Harris Linux advocate Computer Consultant GNU advocate Capslock Consulting Open Source advocate
... Our continuing mission: To seek out knowledge of C, to explore strange UNIX commands, and to boldly code where no one has man page 4.
- 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/
| |