If running X11 as root is not a very good idea, then can anyone mention a method/solution, how to still use a GUI, and not having X11 as root?

  • 2
    Don't run as root as just use sudo when you need to elevate privilege? Why the hell do you NEED to run as root in the first place? – Bruno Rohée May 3 '11 at 8:01
  • can you give more detail? Is it just for X that you require higher privs? If so, Bruno has the answer (and in fact should post it as an answer) – Rory Alsop May 3 '11 at 8:30
  • I don't have an obsd right next to me, that's why I'm asking. So "X11" doesn't runs by default with root priviledges? ok! – LanceBaynes May 3 '11 at 10:05
  • Yeah that's the point X11 is privilege separated on OpenBSD – Bruno Rohée May 3 '11 at 14:18
  • "X11 is privilege separated on OpenBSD" - thank you! – LanceBaynes May 4 '11 at 4:47

(I speak here more generically than in the specific case of OpenBSD.)

X11 needs some direct access to the underlying hardware, something which requires some extra privileges which are not given to just any process (such privileges can be used to mess with memory transfers, e.g. between system memory and hard disks). So there must be some root-or-equivalent involved at some point. However, once the said privileges have been granted, nothing says that the process which runs the X server must keep on being root. Of course, if a non-root-but-with-hardware-access X server gets subverted, it still may gain, theoretically, strong access to the machine through DMA manipulations, but this does not look easy at all.

(Also, there can be totally unprivileged X11 servers which use a framebuffer interface, although this tends not to be very compatible with support for accelerated graphics.)


Running X.org as non-root is now possible as of Feb. 22, 2014 (my emphasis):

In OpenBSD-current, after this commit users of Intel and ATI Radeon graphics which support kernel mode setting (almost all of them) can set machdep.allowaperture back to 0 in the /etc/sysctl.conf configuration and still run the X server.

This means that the X server requires no special privilege to access kernel memory or I/O devices directly, and, thanks to the privilege separation code, that most of the code in the X server will also not run as root. Keeping this special direct access to the hardware through the aperture driver was one of the major drawbacks of privelege separation in X, as pointed out by a paper by Loic Duflot at CANSECWEST 2006.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.