Messages in this thread | | | From | Russell King <> | Subject | Re: disk-destroyer.c | Date | Fri, 21 Jul 2000 22:28:41 +0100 (BST) |
| |
PLEASE DO NOT CC: ME - I DO NOT WANT TWO SETS OF THIS CRAP IN MY MAILBOX.
I have read this entire thread so far, and I'm disgusted by the reaction I'm seeing. Is this the response of a forward thinking constructive development community, or a war zone where features that might improve stuff must be fought off at every corner? Sounds more like a certain commercial company that I want to avoid.
Mark Gray writes: > The thing is, Western Digital has activeX apps on their site which > will do low level Disk diagnostics, which means an activeX app can also > be written to do a low level format (poorly!) or rewrite the firmware. > If root can load a module or write to /dev/kmem there is nothing to > prevent him doing anything to the hardware he feels like, driver or no > driver. If someone gets root on a box then the "admin" did not take > proper precautions, which makes it even less likely that he set > capabilities to prevent a hostile root from "having his way."
Hey, can we stop having a go at Andre please?
Lets look at this from a different point of view that maybe more people can understand. Lets say that by some means, Linus went totally mad and we ended up with a system call thus:
int sys_rm_rf(char *path) { int ret = -EPERM; if (capability(CAP_SYS_ADMIN)) ret = do_rm_rf(path); return ret; }
You are developing a kernel module and program that doesn't have a routine in libc, and you need to use syscall(). The system call that you want to call is a new number and requires root privs, so you give it by numeric ID (but oops, you mis-type it without realising it).
You compile the program (and since you're a good system admin) you compile it outside of root privs. You then su, and run it. Oops, you've just called sys_rm_rf and path was pointing at /.
I bet you'd say that sys_rm_rf SHOULD NOT exist.
Now, by your (and everyone elses) argument, we can do the same thing via the /dev/ioport device, so its ok to have sys_rm_rf included in the kernel.
This is the EXACT same argument that Andre/lkml is fighting over. Either you accept both arguments or neither argument. IMHO you'd have to be really stupid to accept neither argument. Choosing to accept one argument and not the other is not only inconsistent, but non-sensible and you should probably be shipped off to see the men in white coats. _____ |_____| ------------------------------------------------- ---+---+- | | Russell King rmk@arm.linux.org.uk --- --- | | | | http://www.arm.linux.org.uk/~rmk/aboutme.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ ------------------------------------------------- /\\\ |
- 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/
| |