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

[Jamey Sharp]

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.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg-devel/attachments/20110929/ed75a206/attachment.pgp>