[RFC] non-root X
Jesse Barnes
jbarnes at virtuousgeek.org
Fri Jul 3 10:55:06 PDT 2009
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
More information about the xorg-devel
mailing list