[RFC] non-root X

Mark Kettenis mark.kettenis at xs4all.nl
Fri Jul 3 00:02:15 PDT 2009


> 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.


More information about the xorg-devel mailing list