Xserver needs to run as "root" on Linux / was: Re: [Xorg] Server side widgets

[Sean Middleditch]

On Wed, 2004-07-14 at 12:18, Alan Cox wrote:
> On Mer, 2004-07-14 at 17:55, Jakub Piotr CÅ‚apa wrote:
> > But there is a problem with a mallicious user killing a logged in session.
> > 
> > The exclusive keyboard would allow us to configure programs used for 
> > logging in (mingetty, xdm) and make sure no other processes can capture 
> > passwords. It seems secure to me and definitely more flexible than any 
> > builtin kernel login demons.
> 
> You also have to know that the "mingetty" you are looking at is the real
> thing. Thats one thing SAK solves definitively. With regards to
> killing sessions, SAK is assuming console access so the user is also
> typically capable of removing the power, putting an axe through the
> monitor and a number of other hard to defend techniques for killing
> logged in sessions.

a) if you're going to assume that kind of stuff, why not assume they
have access to the hard-disk and can just modify the password database
using external means?

b) it's quite easy to have a local-login on a physically secure
computer.  we have a couple machines here that are locked up in the
counters.  users could destroy the monitor and periphials, but those
won't kill sessions (and thus lose or, much worse, corrupt, data) as
they can be replaced while the machine is running.

c) what about remote logins anyway?  surely any secure login system,
whether the login is actually in-kernel or trusted user-space system,
would be capable of doing full PAM-style authentication.  I could see a
dumb terminal use a locally safe login system to authenticate to a
remote XDMCP server and initiate a session.  even if the local terminal
is destroyed, other remote client protocols are session-aware and won't
just kill the application processes on disconnection, but instead wait
for reconnection from the same or another terminal.

I really do think that easy killing of sessions is bad news.  It _can_
cause corrupt data in a lot of unfortunately non-super-safe applications
(ones which don't write and modify data in a virtually atomic way).
-- 
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.