Control: retitle 856351 xinit does not run as normal user but as root only Control: severity 856351 important Control: merge 856351 903988
This bug really originates in the X server binary (/usr/lib/xorg/Xorg, in the xserver-xorg-core package), not in xinit, but that's not a public interface. xinit is the public interface through which the bug becomes visible. The problem arises where the X server attempts to select a virtual console on which the X display will manifest. In the usual case, the server opens /dev/tty0 in order to perform ioctls on it that are concerned with managing virtual consoles. /dev/tty0 is not itself a virtual console, but is part of that system: it accepts the same ioctls, and anything written to /dev/tty0 goes to whichever virtual console is active at the time of the write. It is not really sensible for ordinary user processes to have access to the writing aspect of /dev/tty0, and by default (via udev) its permissions prohibit access by ordinary users. This means that the X server's open of /dev/tty0 is pretty much guaranteed to fail when the server is invoked by an unprivileged user. The only way to prevent the X server from attempting to use /dev/tty0 is to explicitly tell it which virtual console to use. Via xinit this looks like "xinit -- :0 vt7", where "vt7" tells it to use /dev/tty7. However, even this isn't enough to avoid this class of permissions problem. When the X server attempts to use a virtual console, whether selected automatically via ioctls or specified on the command line, its first action is to open that virtual console device. If the virtual console was otherwise unused, which is what it tries to do by default, then at this point the virtual console device probably also has restrictive permissions that prevent it being opened by an unprivileged user. To avoid getting a permissions error on a virtual console, then, the user must select for the X display a virtual console that ey already owns, and must explicitly specify it on the xinit command line. Fortunately, in the common case where the X server is being invoked *from* a virtual console, which will not be otherwise needed until the X server terminates, it is possible for the X server to use that same virtual console. The startx wrapper for xinit does precisely this, which is why it doesn't exhibit the same problem. Those who use xinit directly should not be required to specify a virtual console. By default a suitable one should be selected and allocated automatically, in a way that doesn't require any special privileges of the invoking user. This allocation should include having the virtual console's ownership set to the invoking user, for the duration of its use by the X server. -zefram
