On my notebook, a fully updated ~amd64, I use no display manager; I log in in a virtual console and say startx (my .xinitrc startx lumina, but this does not matter now). Until yesterday everything worked fine (xorg-server with USE=suid). Yesterday I rebooted the notebook (after a long period during which I only used hibernate in X mode). startx produced a fatal server error (EE) parse_vt_settings: Cannot open /dev/tty0 (Permission denied) If I log in as root and say startx, everything works fine. I wanted an X session urgently, and so I used a big hammer: chmod 666 /dev/tty0 (as root), then startx (as me). Now (EE) xf86OpenConsole: Cannot open virtual console 7 (Permission denied) OK, a bigger hammer: chmod 666 /dev/tty* (as root), startx (as me). Now I got a normal picture on screen, but neither keyboard nor mouse work. ~/.local/share/xorg/Xorg.0.log contains a lot of (EE) xf86OpenSerial: cannot open device /dev/input/event* (Permission denied) with many numbers *. Another big hammer: chmod 666 /dev/input/event* (as root), startx (as myself). Bingo! My lumina desktop works fine. Then I thought: /dev/tty* belong to root:tty, /dev/input/event* belong to root:input. So, I included myself in the groups tty and input, and retried with virgin permissions. No go: (EE) xf86OpenConsole: Cannot open virtual console 7 (Permission denied) (interesting: no message about /dev/tty0). xorg-server is compiled with USE=suid: bilbo ~ # ls -l /usr/libexec/Xorg* -rwx--x--x 1 root root 2385472 Jan 12 23:41 /usr/libexec/Xorg* -rws--x--x 1 root root 14392 Jan 12 23:41 /usr/libexec/Xorg.wrap* Theoretically, Xorg.wrap should do all the things requiring root permissions, and Xorg dos not need them. So, I tried a *slightly* smaller hammer: chmod 4711 /usr/libexec/Xorg (as root), startx (with virgin permissions, as me). X starts and works normally. So, how can I work without suiding /usr/libexec/Xorg? And what has changed recently? (by the way, there is a recent thread on the forum about the same matter: startx works from root but not an ordinary user, so, it seems, it's not just me). For information: bilbo ~ # eix x11-base/xorg-server [I] x11-base/xorg-server Available versions: 1.20.10(0/1.20.10) **9999(0/9999)*l {debug dmx doc +elogind ipv6 kdrive libressl minimal selinux suid systemd +udev unwind wayland xcsecurity xephyr xnest xorg xvfb} Installed versions: 1.20.10(0/1.20.10)(11:41:16 PM 01/12/2021)(elogind suid udev xorg -debug -dmx -doc -ipv6 -kdrive -libressl -minimal -selinux -systemd -unwind -wayland -xcsecurity -xephyr -xnest -xvfb) Homepage: https://www.x.org/wiki/ https://gitlab.freedesktop.org/xorg/xserver/xorg-server Description: X.Org X servers
BTW, I don't use systemd
Have you read the news item from June? eselect news read 2020-06-24-xorg-server-dropping-default-suid
(In reply to Matt Turner from comment #2) > Have you read the news item from June? > > eselect news read 2020-06-24-xorg-server-dropping-default-suid Yes, I have read it. I use a desktop profile (namely, plasma), and have elogind installed. The USE flag elogind is globally enabled. Without USE=suid X did not work for a long time (I mean when I use startx, not a display manager). But with USE=suid it worked fine until very recently.
Follow the troubleshooting part of https://wiki.gentoo.org/wiki/Non_root_Xorg
(In reply to Piotr Karbowski from comment #4) > Follow the troubleshooting part of https://wiki.gentoo.org/wiki/Non_root_Xorg OK thanks. Adding elogind to the boot runlevel has helped. But an interesting question remains: whas has been broken quite recently in Xorg with USE=suid? Why it worked for so long and suddenly stopped working?
Sounds a bit similar to https://bugs.gentoo.org/764557 But we lack information and steps to reproduce it, if you can join it and confirm/deny, it would be great.
