Subject: Re: increasing a process's max data size
To: Brett Lymn <blymn@baesystems.com.au>
From: Greywolf <greywolf@starwolf.com>
List: port-sparc
Date: 09/08/2003 20:45:49
Thus spake Brett Lymn ("BL> ") sometime Tomorrow...

BL> On Mon, Sep 08, 2003 at 02:20:34AM -0400, der Mouse wrote:
BL> > > Any userland program that is able to produce a kernel panic mean
BL> > > there is a kernel bug - no ifs no buts - userland must not be able to
BL> > > crash the kernel no matter what.
BL> >
BL> > dd if=/dev/zero of=/dev/mem
BL> >
BL>
BL> Specious.  As others have observed you need to be root to do that.

The argument was irrelevant of permissions.  A userland process is a
userland process, privileges aside.

On a properly configured (and STABLE!) system, NO userland process
should be able to panic the kernel, not even as root.

I will make the stipulation that it needs to be in multi-user mode to
qualify, though; crashing a kernel in single-user mode is pretty well
useless, even if possible.

BL> Squid, even if it is started by root, switches it's user id to a
BL> configurable one fairly early on, in fact, if you are using the
BL> default squid tcp/ip port then you don't need to be root to start it.
BL> Normally squid runs as the id nobody - that userid being able to cause
BL> a kernel panic then there is a problem.

Granted; but privilege is irrelevant, really.

[I'm reminded of a bug in SunOS 3.2 by which an improperly called
 execve() crashed the kernel quite readily, even when run as a normal
 user...]

				--*greywolf;
--
"Hello, I've just upgraded my OS to Windows 2000..."
"Yes...?"
"Well, my computer doesn't work now."
"Yes, you just said that a second ago."