lkml.org 
[lkml]   [2000]   [Jul]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.703 / U:0.176 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site