[RFC] Xdummy standalone binary or "-dummy" switch

[Peter Hutterer]

On Thu, Sep 29, 2011 at 12:10:29PM -0700, Jamey Sharp wrote:
> On Fri, Sep 30, 2011 at 12:10:05AM +0700, Antoine Martin wrote:
> > As discussed a while back [1], there are a number of issues which can
> > only be resolved by using an Xdummy binary server in order to replace
> > Xvfb with a more modern equivalent. The only alternative I can think of
> > would be to add a "-dummy" command line option to Xorg, this feels
> > somewhat more intrusive/dangerous. Or maybe there is another way I
> > haven't thought about?
> 
> I think there's a third option here, yeah.
> 
> > First, what is wrong with Xvfb?
> > It does not support modern extensions like RandrR which I need for my
> > Xpra fork [2]
> 
> Also wrong with Xvfb: I want it and the other DDXes to die. :-)
> 
> > Why can't people just use Xorg as it is with the dummy driver?
> > Well, you can but this involves using Xdummy's [3] dodgy LD_PRELOAD
> > hacks to workaround some of the limitations built into the Xorg server.
> > 
> > What are those limitations?
> > 1) root-only limitations on the configuration options for the location
> > of the config and log files.
> > This makes sense when the server runs as root and gets (almost?) full
> > access to all system memory, but not when the only device driver loaded
> > is the "dummy" one.
> > Any user should be able to launch an Xdummy instance without needing
> > root or special permissions.
> > (I've tested this with a quick and dirty patch [4])
> 
> The same goes for the video-nested driver. It might make sense for fbdev
> or KMS drivers too: if you have permission for the device node, you
> should be able to run an X server on it any way you like.
> 
> Further, I think checking whether the server is running as root is
> always the wrong check. I think the *right* check is to test whether the
> server's effective UID is the same as its real UID. Then the server can
> be paranoid about config files and options only when it's running with
> different permissions than its caller otherwise would have.
> 
> For example, there's nothing wrong with a non-root user setting a custom
> module path. The only problem is if a non-root user, running a SUID X
> server, can use a custom module path to execute harmful code with
> elevated permissions. Similarly, setting a log-file path is only a
> problem if you can overwrite a file you couldn't otherwise overwrite.
> 
> I don't think this calls for an "unbreak me please" flag; I think the
> normal behavior of the server should be fixed.
> 
> > 2) Xorg server probing devices.
> > Now this one I am less sure about, maybe I just don't know the proper
> > incantations. I've tried all the options I could find to try to prevent
> > all the probing that goes on (explicitly specifying the "void" driver
> > for keyboard and mouse, etc)
> > In the end, I just hacked the code to ignore them all for now [5]
> 
> I use these settings in my nested/dummy testing, which seem to suffice
> for me:
> 
> Section "ServerFlags"
>     Option "AutoEnableDevices" "false"
>     Option "AutoAddDevices" "false"
> EndSection
> 
> I'm not sure even AutoEnableDevices is relevant; I think AutoAddDevices
> is the important flag. You shouldn't need to add any input devices, not
> even "void" ones.

There's little need for AutoEnableDevices ever. I think the main reason it
is there is because XI 1.3- had a rather different notion of
enabled/disabled devices than we have now.

If your nested driver needs to disable this, we could add a hook to the
DDX to let a driver toggle AAD defaults. 

Cheers,
  Peter

> If that's all the issues you've had, I'm hoping that just fixing the
> stupid "am I root?" checks will take care of everything you need.
> Anything missing?
> 
> Jamey