Rootless

Revision 3 as of 2009-11-03 17:51:34

Clear message

Summary

For video drivers that support kernel mode-setting (KMS), X can be set up to run as a non-root user.

Background

Historically, X has been responsible for setting up the graphics modes (resolutions, refresh rates, etc.) X did this by talking to the hardware directly, which it could only do if it ran with root privileges. The reason X was tasked with doing this work was to keep graphics as platform-agnostic as possible, so the same graphics code could be used for BSD and other *nix flavors.

Today, the feeling is that this mode-setting logic should be moved into the kernel. Some video drivers, such as the -intel driver, now have this 'kernel mode-setting' (KMS) ability implemented. In karmic, -intel already uses KMS by default, and the -ati driver will run with KMS if the kernel is booted with the 'radeon.modeset=1' parameter, but it is not set as the default due to stability concerns. But other drivers in Karmic, such as -fglrx and -nvidia, do not support KMS at all.

Requirements

  • Framebuffer or kernel mode-setting enabled video drivers ONLY:

    • fbdev (ARM, etc.)
    • -intel [DONE] - Available by default in Karmic
    • -ati [DONE] - Configurable in Karmic with minor stability issues, will likely be available by default in Lucid
    • -nouveau [IN PROGRESS] - Code exists, requires special kernel and X to test. Does not work on a lot of hardware, has stability issues on others.

    • -psb [IN PROGRESS] - Coming soon

    • -openchrome [IN PROGRESS]
    • -nv, -nvidia, -fglrx, others: Not planned at this time
  • Non-root access to certain device files
    • tty/VT probing and ownership
    • input devices
    • DRM ioctls - (should be largely done already)
  • Drop suid bit on /usr/bin/X

Discussion

A lot of the work needing done in X and in the kernel to make rootless-X possible is in place. Much of the remaining work is "plumbing" such as ensuring that device nodes are set up with permissions to allow a user process (i.e. X) to read/write to them. This includes ttys, input devices, and so on. Obviously you don't want to leave them owned as root but with global read/write privs; however if you give ownership of them to one user, then it makes user switching more complex.

References