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

[Antoine Martin]

[snip]
I meant to reply to Jamey, but couldn't find his reply in my mailbox..
>>> 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.
OK, I've looked for at all the places that use getuid or getuid, and found:
* os-support/* some checks for euid!=0 for console stuff / KeepTTY,
which I have left alone
* parser/write.c also left alone for now - I can look into it too if you
want.
* common/xf86Init.c: ddxProcessArgument and ddxUseMsg patched, see
attachment.

With just this small patch and the correct xorg.conf as per below I can
run "dummy" non-root without problems. Does it look acceptable?

The only other patch required to make this useful for non-root users is
the one that allows for absolute config files I had posted earlier,
otherwise I don't see how one can launch using custom config files as
the "-config" option does not seem to honour the "-configdir" option.
Obviously this would now need an extra euid!=uid check.
Or am I missing something again?

--- xfree86/parser/scan.c    2011-08-05 12:59:02.000000000 +0700
+++ xfree86.euid/parser/scan.c    2011-09-30 12:59:44.935338707 +0700
@@ -739,6 +739,17 @@
     int cmdlineUsed = 0;
     FILE *file = NULL;
 
+    if (cmdline && cmdline[0]=='/') {
+        filepath = strdup(cmdline);
+        file = fopen(filepath, "r");
+        if (file) {
+            configFiles[numFiles].file = file;
+            configFiles[numFiles].path = filepath;
+            numFiles++;
+            return strdup(cmdline);
+        }
+    }
+
     pathcopy = strdup(path);
     for (template = strtok(pathcopy, ","); template && !file;
          template = strtok(NULL, ",")) {
>>> 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.
That did the trick!
>> 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?
I don't think so - works-for-me(tm)
I guess distributors will then have to ship two copies of /usr/bin/Xorg,
one that is suid-root and one that isn't? (until we can get rid of the
suid one entirely, one day)

Thanks
Antoine
>> Jamey
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: xdummy-euidchecks.patch
URL: <http://lists.x.org/archives/xorg-devel/attachments/20110930/130f8d32/attachment.txt>