Re: kill -9 <pid of X>

Olaf Titz (olaf@bigred.inka.de)
Thu, 13 Aug 1998 13:57:33 +0200


> When not under X, rather than having a SVGAlib library and compiling
> everything to be suid root, you have a root wrapper executable, which is
> suid, gets the screen changes modes, forks, gets rid of it's suid
> privileges and does an exec(). You now have a normal user that has access

Every time someone mentions a flawed svgalib program on bugtraq I
point them to the suid wrapper for svgalib I wrote ages ago. :-)
Nothing in the svgalib programs I run[1] on my box ever sees UID 0 and it
works properly.

That one simply execs instead of being a watchdog daemon, but perhaps
we should consider the latter idea further:

> to the screen, but more importantly, you _also_ have a root wrapper you
> trust. That root wrapper can handle SAK (the kernel knows who it is,
> because it already had to register as a console switcher process).
> (The root wrapper doesn't just go away: it stays in the background,
> waiting for its child do die, or waiting for the kernel to ask it to
> switch consoles).

Okay, that looks very valid, but for one point: who does the console
switching? Console switching implies video mode switching so this has
to be done from the svgalib program itself, unless you link the
wrapper with svgalib too, which is a bit messy and would require
probably incompatible changes in svgalib (no two console switchers
fighting for the signals).

> properly in user mode. Why are there still people who want to try to
> change the kernel before they have even considered fixing SVGAlib etc?

Because svgalib is somewhat the wrong approach. It's device drivers in
user space. The same thing for XFree86.

> Linux isn't a Windows NT where you add cruft in the kernel to get around
> cruft in user programs.

Video drivers in the kernel add cruft here to _get rid_ of the cruft
in user space, where it jeopardizes system stability. And that cruft
is result of the horrible mess the hardware it deals with is.
(Read the description of the 3c501 driver for comparison ;-)

> suid(0)+suid(xxx) rather than just suid(0)) and (b) SVGAlib doesn't
> require that the whole application runs with root privileges.

Actually it doesn't since some years ago the IOPERM environment
variable was added which means support for the above-mentioned wrapper
utility of the same name.
See <URL:http://sites.inka.de/~bigred/sw/ioperm.txt> dated March 28,
1994. I don't know exactly why this program wasn't simply added to the
svgalib distribution back then. Instead people keep claiming that you
need root even for running games you don't have the source for, which
is of course horrible.

olaf

[1] actually "ran"; since I installed a Millennium II it doesn't work
any more because of missing driver. As far as I'm concerned, it's gone
for good.

-
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.altern.org/andrebalsa/doc/lkml-faq.html