X.org-Absturz mit Fehler „drmSetMaster failed: Permission denied“

Kategorien: Software

Normalerweise kann man in das Paketsystem von Debian Stable großes Vertrauen haben. Es ist sehr selten, daß ein Update ein funktionierendes System lahmlegt, aber nichtsdestotrotz kommt es vor. So ist es mir heute ergangen. Nach dem Update startete der X.org-Server, d.h. die graphische Benutzeroberfläche, nicht mehr. In der Logdatei ~/.local/share/xorg/Xorg.0.log gab es folgende Fehlermeldung:

[    26.401] (EE) 
Fatal server error:
[    26.401] (EE) xf86OpenConsole: Cannot open virtual console 7 (Permission denied)
[    26.401] (EE) 
[    26.401] (EE) 
Please consult the The X.Org Foundation support 
     at http://wiki.x.org
 for help. 

Eine (nicht empfehlenswerte) Änderung der Zugriffsrechte auf /dev/tty7 hat nur einen neuen Fehler hervorgebracht:

[   625.346] (EE) modeset(0): drmSetMaster failed: Permission denied
[   625.346] (EE) 
Fatal server error:
[   625.346] (EE) AddScreen/ScreenInit failed for driver 0
[   625.346] (EE) 
[   625.346] (EE) 
Please consult the The X.Org Foundation support 
     at http://wiki.x.org
 for help. 

Das offenbar auf Systeme mit dem i915-Graphiktreiber von Intel beschränkte Problem hat seine Ursache darin, daß ich den X-Server nicht mithilfe eines Login-Dienstes wie GDM als Benutzer root starte, sondern manuell mithilfe von startx(1) auf der Konsole, was dazu führt, daß er „nur“ mit Benutzerrechten läuft. Das ist seit 2009 möglich und erhöht die Sicherheit. Anfänglichen Problemen dieser Funktion konnte man damit begegnen, das Binary /usr/bin/Xorg manuell mithilfe von chmod(1) wieder mit dem Setuid-Bit zu versehen, aber es scheint, als ob dieser Trick heute nicht mehr funktioniert. Jedenfalls lief mein diesbezüglicher Versuch ins Leere und produzierte dieselbe Fehlermeldung. Was funktionierte, war, X.org direkt als root per sudo startx zu starten, sodaß immerhin klar war, daß kein Hardware-Fehler oder ein tiefgreifendes Konfigurationsproblem beim Treiber vorlag. Doch führt dies dazu, daß nicht nur X.org, sondern sämtliche Programme mit root-Rechten gestartet werden, was aus Sicherheitsgründen natürlich nicht empfehlenswert ist.

Eine Lösung in dem Sinne, daß man X.org weiter als normaler Benutzer ausführen könnte, existiert offenbar nicht; ein entsprechender Fehlerbericht aus 2019 ist ungelöst. Warum das Problem auf meinem System erst mit dem heutigen Update der drei Pakete xserver-common, xserver-xorg-core und xserver-xorg-legacy jeweils von Version 2:1.20.4-1 auf Version 2:1.20.4-1+deb10u1 auftrat, kann ich nicht erklären. Erstaunlicherweise war das Problem auch nach einem Downgrade der Pakete auf die frühere Version nicht beseitigt, was mich dann zwang, doch meine Zeit hierfür statt für meine wissenschaftliche Arbeit aufzuwenden.

Eine Umgehungslösung liegt darin, X.org als root zu starten. Dafür gibt es seit einiger Zeit offenbar ein besonderes Wrapper-Programm, das unter Debian im Paket xserver-xorg-legacy enthalten ist. Dieses Paket bringt eine Konfigurationsdatei /etc/X11/Xwrapper.config mit, deren Inhalt um folgende Zeile ergänzt werden muß:

needs_root_rights=yes

Danach sollte X.org wieder per startx(1) gestartet werden können, nun allerdings mit root-Rechten. Die einzelnen Programme laufen dagegen nur mit Benutzerrechten. Das entspricht der historischen Situation von vor 2009, ist aber besser als eine nicht funktionierende graphische Benutzeroberfläche und sicherer als der oben erwähnte Ansatz mit sudo(1), bei dem alle Programme als root laufen würden.

Möglicherweise ist das Problem mit meiner sehr spezifischen Systemkonfiguration erklärbar. Ich nutze immerhin ein fast zehn Jahre altes Laptop mit dem bekanntermaßen schwierigen i915-Graphiktreiber, starte die graphische Benutzeroberflächte manuell von der Konsole und nutze OpenRC statt Systemd. Die vielen Fehlerberichte im Internet lassen aber vermuten, daß das Problem nicht zwingend allein hierauf zurückzuführen ist. Zu hoffen bleibt, daß später ein Start von X.org mit „normalen“ Benutzerrechten wieder möglich wird.