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

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