Running X as an unprivileged user

Christopher James Halse Rogers christopher.halse.rogers at canonical.com
Sun Jun 27 16:51:55 PDT 2010


On Fri, 2010-06-25 at 15:04 +0100, Daniel Stone wrote:
> On Fri, Jun 25, 2010 at 11:12:49PM +1000, Christopher James Halse Rogers wrote:
> > It seems that almost all of the work required to run X without root
> > privileges has been done, and there are just a couple of loose ends to
> > tie up before it can work - at least for KMS drivers.
> > 
> > Apart from opening /proc/mtrr for writing, which isn't used by any of
> > the drivers I've inspected and certainly by none of the KMS drivers, it
> > seems the last problem is backlight handling which requires
> > prodding /sys/class/backlight/*/brightness.  It seems that the way to
> > deal with this would be to get a /dev/backlight device interface for
> > which udev could set appropriate permissions.  This would also clean the
> > Intel DDX code somewhat as it wouldn't have to iterate over the list of
> > possible /sys paths.
> 
> Why not just have ConsoleKit set the ownership, presumably as you'd have
> it doing for /dev/input?

I've got a note here that ConsoleKit won't do what we want, but looking
at it again I'm not sure why.  I'll look again!

>  That still doesn't solve the revoke() problem
> though (i.e. what happens when you switch to another session - the
> original server could still have its /dev/input FDs open, leaking all
> your passwords).

Right.  This prevents us from running X as the user who is logging in
and changing the /dev/input ownership to that user.  We can mitigate
this by running all X servers as a dedicated system user, though.  That
leaves the session-switch situation the same as we currently have it
with multiple X servers running as root.

That's not as ideal as having X running as the logged-in user with the
input devices owned by the local console + a working revoke() syscall,
but I don't think it's worse than the status quo in terms of password
snooping and limits some of the damage a broken or compromised X could
do.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg-devel/attachments/20100628/ee8aeac8/attachment.pgp>


More information about the xorg-devel mailing list