Messages in this thread | | | From | Myrddin Emrys <> | Subject | Re: The Full Explaination ... (re: disk-destroyer.c) | Date | Fri, 21 Jul 2000 12:02:34 -0500 |
| |
On Thu, 20 Jul 2000 22:29:20 -0700 (PDT) you sent this message:
>On Thu, 20 Jul 2000, Myrddin Emrys wrote: > >> On Thu, 20 Jul 2000 19:09:19 -0700 (PDT) you sent this message: >> >> >I try to provide a protective layer to the hardware and everybody says it >> >is not needed. >> >> Perhaps you were not explaining your position clearly. I gathered that the >> behavior, as described, was perfectly valid, just dangerous. You, on the >> other hand, are now clarifying that the behavior of the system, when those >> bytes were sent, is not correct. In other words, it's possible for the >> system to 'accidentally' fry a hard drive... is this correct? > >Hi Myrddin, > >You are correct I have not explained the magnitude, so here goes. <snip> >All I want is to protect JOE SIX-PACK new user that is not security savy >from losing his hardware with the kernel assisting in the destruction. >Is this to much to ask?
Hmm. I guess that your and my definition of 'Joe Six-Pack' is different. In my world, Joe Six-Pack won't be compiling and running disk2brick.c on a Linux box. Joe Six-ack has difficulty even leaving X without hand holding.
But that is a moot point. I think, idealistically, your position is correct. What I think you are incorrect about is the urgency with which you advocate your position. The fix is not urgent, it's minor. There are ways of frying hardware in userspace, a real where Joe Six-Pack is FAR more likely to be... protection in the kernel against one specific hack adds little security.
As someone else pointed out, now is not the time to be adding changes like this (just before a stable release). Offer the patch after the next stable kernel, when less urgent changes are easier to get in. Remember that you're not patching a gaping hole... you're blocking one of a hundred ways that root can fry hardware. There are many other ways still to go, so having 99 ways to fry the system, instead of 100, is not that big of a fix. Eventually we may get down to 0, but until we get close to that ideal, each cemented hole is a minor change not urgent enough to risk destabilizing an even release.
Myrddin
- 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/
| |