[RFC] non-root X

[Jesse Barnes]

On Fri, 3 Jul 2009 09:02:15 +0200 (CEST)
Mark Kettenis <mark.kettenis at xs4all.nl> wrote:

> > Date: Wed, 1 Jul 2009 13:15:03 -0700
> > From: Jesse Barnes <jbarnes at virtuousgeek.org>
> > 
> > For Moblin, we'd like to be able to run X as a non-root user, so
> > with that in mind I spent a few hours looking at what it would take
> > to get X running w/o root perms on the latest bits using the
> > xf86-video-intel driver (note Dave did this about a year ago, but I
> > guess the bits didn't make it upstream). Turns out now that all the
> > pieces are in place it was really easy. X needed root on Linux for
> > a few things: 1) I/O probing
> >   2) tty/VT probing & ownership
> >   3) some DRM ioctls
> >   4) some PCI related probing
> >   5) input perms
> > 
> > However, with a KMS enabled driver that doesn't do I/O access, (1)
> > and (4) aren't really necessary anymore.  For (3), just a couple of
> > ioctls need to have their "root only" status stripped (safely I
> > think).  And for (2) and (5), distro pam scripts can take care of
> > things (as long as X is started on a tty that has had its
> > ownership/perms modified appropriately).
> > 
> > So this small patch is all that's necessary on the X side (the DRM
> > patch is trivial, and half of it has already been posted to
> > dri-devel). It's a big hackish, so I'm just requesting comments at
> > this point.  I'd like to do the -nohwaccess part better, but think
> > doing it well will require a driver ABI change (maybe just a new
> > flags field that indicates whether the driver needs I/O ports
> > enabled, or we can push the xf86EnableIO call into drivers as
> > needed).
> 
> Jesse, thinking about I/O ports as an all-on/all-off thing is too
> PC-centric I'm afraid.  Or actually, the whole concept of I/O "ports"
> is.  On most other architectures (SPARC, PowerPC, ARM to name a
> couple) I/O cycles on the PCI bus are generated by memory mapping just
> like what is done for memory cycles.  Therefore, I think the drivers
> should really exlicitly map the I/O space they need using
> pci_device_map_range().  Perhaps a seperate call is needed to map
> legacy VGA I/O space; this should probably tie in with the (mythical?)
> VGA arbiter that has been talked about.

Oh I know it. :)  Drivers really should be more specific about their
needs.  If we can wrap the actual legacy I/O port requirement into the
VGA arbiter, I think the rest will be taken care of by PCI device
mapping and perms (leaving aside funky busses).

-- 
Jesse Barnes, Intel Open Source Technology Center