xserver-xorg-legacy
xserver-xorg-legacy
Wozu ist dieses Teil eigentlich gut? Soweit ich verstanden habe, soll es doch dafür sorgen, dass, falls auf einer Maschine der xserver für einen "einfachen" User (genauer /usr/lib/xorg/Xorg) nicht ohne SUID-Bit läuft (ich habe noch keine in den Fingern gehabt bei der das funktioniert hätte ), der dann genau dies bewerkstelligt. Hier (stretch) tut er das jedenfalls nicht.
Grüße, Günther
Grüße, Günther
Zuletzt geändert von guennid am 24.12.2018 12:08:55, insgesamt 2-mal geändert.
Re: xserver-xorg-legacy
Ohne die Installation von libpam-systemd habe ich das auch noch nicht hinbekommen!? Hier wird allerdings das Gegenteil behauptet:
viewtopic.php?f=15&t=168996&hilit=libpam+systemd
Re: xserver-xorg-legacy
Verantwortlich ist wohl libpam-systemd. Installation von libpam-elogind (devuan-ascii) hat nicht geholfen. Also: xserver-xorg-legacy wieder deinstallieren und SUID-Bit für /usr/bin/xorg/Xorg wieder setzen.
Grüße, Günther
Grüße, Günther
Re: xserver-xorg-legacy
Nach der Installation von xserver-xorg-legacy ist das suid-Bit eigentlich (?) gesetzt.
Zum Konfigurieren hast Du die Datei /etc/X11/Xwrapper.config.
Darin wird festgelegt, wer einen neuen X server starten darf.
Standard ist: Nur von Konsole dürfen normale User einen X server starten:
Das kannst Du ändern z.B. zu
Was genau geht bei Dir nicht?
Zum Konfigurieren hast Du die Datei /etc/X11/Xwrapper.config.
Darin wird festgelegt, wer einen neuen X server starten darf.
Standard ist: Nur von Konsole dürfen normale User einen X server starten:
Code: Alles auswählen
allowed_users=console
Code: Alles auswählen
allowed_users=anybody
needs_root_rights=yes
Die Vernunft kann einem schon leidtun. Sie verliert eigentlich immer.
Re: xserver-xorg-legacy
So etwa hatte ich das auch vermutet, war aber nicht. Neustart vonnöten?MartinV hat geschrieben:Nach der Installation von Debian xserver-xorg-legacy ist das suid-Bit eigentlich (?) gesetzt.
Und wenn's das ist, was das Paket im Endeffekt macht/machen sollte - das kann ich auch ohne legacy und ohne /etc/X11/Xwrapper.config
Rechner friert nach startx komplett ein. Nichts geht mehr.MartinV hat geschrieben:Was genau geht bei dir nicht?
Grüße, Günther
Re: xserver-xorg-legacy
X und Xorg sind etwas verschachelt verlinkt und versteckt. Zusätzlich gibt es noch ein Xorg.wrap.
Schau mal in den Ordner /usr/lib/xorg. Dort finde ich:
Xorg.wrap hat das suid-bit.
Schau mal in den Ordner /usr/lib/xorg. Dort finde ich:
Code: Alles auswählen
$ ls -l /usr/lib/xorg
insgesamt 2420
drwxr-xr-x 5 root root 4096 Nov 1 11:09 modules
-rw-r--r-- 1 root root 25699 Okt 25 20:15 protocol.txt
-rwxr-xr-x 1 root root 2427776 Okt 25 20:15 Xorg
-rwsr-sr-x 1 root root 14608 Okt 25 20:15 Xorg.wrap
Das klingt nach einem Grafikkarten-Problem. Manche (?) alten Treiber, vllt. auch neue nvidias, benötigen X mit suid-Rechten. Der Grund für den Fehler könnte (tm) natürlich auch ein ganz anderer sein. Was hast Du für eine Grafikkarte?Rechner friert nach startx komplett ein. Nichts geht mehr.
Die Vernunft kann einem schon leidtun. Sie verliert eigentlich immer.
Re: xserver-xorg-legacy
Ich vermute Xorg.wrap kommt mit legacy. Hier ist es jedenfalls nach der Deinstallation nicht (mehr) vorhanden.
Ziemlich altes Teil, aber wie gesagt: Ich besitze keine Maschine, bei der's funktioniert hätte. Belassen wir's dabei.
Grüße, Günther
Code: Alles auswählen
VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 04)
Grüße, Günther
Re: xserver-xorg-legacy (entfernt)
Ich "öffne" das nochmal, weil meine eigentliche Frage, was denn nun dieses Paket genau macht, mir immer noch nicht ausreichend klar ist. Ich habe mal im Netz gesucht mit folgenden Suchbegriffen: "manpage xserver legacy" Das hier 1) habe ich als ersten Link erhalten:
Der Sinn des letztzitierten Satzes erschließt sich mir kaum: "Voreingestellt wird Xorg.wrap die Ausführung des realen xservers nur erlauben von Login-Sitzungen auf einer physikalischen Konsole". Geht's hier darum, dass Xorg.wrap voreingestellt verhindert, dass der xserver via Login-Manager gestartet wird? Das wäre für mich uninteressant, da ich grundsätzlich keine Login-Manager benutze und die GUI ausnahmslos von einem tty aufrufe, auf dem ich mich einlogge. Ansonsten verstehe ich nicht, was hier mit login session und physical console gemeint ist.
Falls ich das im Wesentlichen richtig verstanden habe, dann scheint ...legacy weder mit der angegebenen noch mit irgend einer anderen GraKa in meinem Besitz defaultmäßig zu funktionieren.
Irgendwie kommt mir das ziemlich strange vor, dass ich mich jetzt mit der Konfiguration eines Paketes herumschlagen muss, das offenbar nichts anderes tut, als das, was jahrzehntelang Standard war, mehr schlecht als recht, wenn überhaupt, weiter zu gewährleisten, zumal ich diesen Standard durch ein simples Rechtesetzen für Xorg, ebenfalls bewirken kann.
Grüße, Günther
1) https://manpages.debian.org/stretch/xse ... .5.en.html
Ich übersetze mir das dahingehend, dass ...legacy/Xorg.wrap nachschaut (bei der eingebauten Graka?) ob der xserver Root-Rechte benötigt, und den xserver dann mit diesen Rechten startet, falls für nötig befunden. Habe ich das so richtig verstanden?The Xorg X server may need root rights to function properly. To start the Xorg X server with these rights your system is using a suid root wrapper installed as /usr/lib/xorg/Xorg.wrap which will execute the real X server which is installed as /usr/lib/xorg/Xorg.
By default Xorg.wrap will autodetect if root rights are necessary, and if not it will drop its elevated rights before starting the real X server. By default Xorg.wrap will only allow executing the real X server from login sessions on a physical console.
Der Sinn des letztzitierten Satzes erschließt sich mir kaum: "Voreingestellt wird Xorg.wrap die Ausführung des realen xservers nur erlauben von Login-Sitzungen auf einer physikalischen Konsole". Geht's hier darum, dass Xorg.wrap voreingestellt verhindert, dass der xserver via Login-Manager gestartet wird? Das wäre für mich uninteressant, da ich grundsätzlich keine Login-Manager benutze und die GUI ausnahmslos von einem tty aufrufe, auf dem ich mich einlogge. Ansonsten verstehe ich nicht, was hier mit login session und physical console gemeint ist.
Falls ich das im Wesentlichen richtig verstanden habe, dann scheint ...legacy weder mit der angegebenen noch mit irgend einer anderen GraKa in meinem Besitz defaultmäßig zu funktionieren.
Irgendwie kommt mir das ziemlich strange vor, dass ich mich jetzt mit der Konfiguration eines Paketes herumschlagen muss, das offenbar nichts anderes tut, als das, was jahrzehntelang Standard war, mehr schlecht als recht, wenn überhaupt, weiter zu gewährleisten, zumal ich diesen Standard durch ein simples Rechtesetzen für Xorg, ebenfalls bewirken kann.
Grüße, Günther
1) https://manpages.debian.org/stretch/xse ... .5.en.html
Re: xserver-xorg-legacy
Ich glaube eher, daß Xorg.wrap nur in der Konfigurationsdatei /etc/X11/Xwrapper.config nachschaut, ob es X mit root-Rechten starten soll.guennid hat geschrieben:24.12.2018 12:08:35Ich übersetze mir das dahingehend, dass ...legacy/Xorg.wrap nachschaut (bei der eingebauten Graka?) ob der xserver Root-Rechte benötigt, und den xserver dann mit diesen Rechten startet, falls für nötig befunden. Habe ich das so richtig verstanden?
Dafür die Zeile:
Code: Alles auswählen
needs_root_rights=yes
Das ist eine Kompromißlösung, die ein bißchen Sicherheit geben soll.guennid hat geschrieben:24.12.2018 12:08:35"Voreingestellt wird Xorg.wrap die Ausführung des realen xservers nur erlauben von Login-Sitzungen auf einer physikalischen Konsole".
Da X als suid-Programm mißbraucht werden könnte, soll es nur von Konsole/tty aus gestartet werden dürfen. Es ist nicht erlaubt, daß irgendein Programm oder der User X innerhalb einer bereits laufenden X-Sitzung startet. (Wie Login-Manager das handhaben, weiß ich nicht.)
Es gibt diese drei Varianten:
Code: Alles auswählen
allowed_users=console
allowed_users=root
allowed_users=anybody
Die Installation des Paketes allein ändert erst einmal nichts (soweit ich sehe). Damit X als root gestartet wird, brauchst Du die Konfiguration:guennid hat geschrieben:24.12.2018 12:08:35Falls ich das im Wesentlichen richtig verstanden habe, dann scheint ...legacy weder mit der angegebenen noch mit irgend einer anderen GraKa in meinem Besitz defaultmäßig zu funktionieren.
Code: Alles auswählen
allowed_users=console
needs_root_rights=yes
Die Vernunft kann einem schon leidtun. Sie verliert eigentlich immer.
Re: xserver-xorg-legacy
Wenn du da recht hast, dann ist das genau das, was mich ärgert. Ich soll mich jetzt umständlich mit etwas auseinandersetzen, dessen einziger Sinn ist, einen Zustand wieder herzustellen, der jahrzehntelang Standard war und den ich ebensogut durch eine simple Rechteänderung bewirken kann. Oder so rum: Mir ist nicht nicht klar, ob die Benutzung von ...legacy (im Falle das rootloses X aus welchem Grunde auch immer nicht funktioniert) irgendeinen Sicherheitsgewinn gegenüber dem händischen Setzen des SUID-Bits bringt. Um Missverständnisse zu vermeiden: Ich kritisere nicht das Bemühen um rootloses X.Martin5 hat geschrieben:Die Installation des Paketes allein ändert erst einmal nichts (soweit ich sehe). Damit X als root gestartet wird, brauchst Du die Konfiguration:
Grüße, Günther
Re: xserver-xorg-legacy
Der frühere Standard war: X als root. Der neue ist: X ohne root.
xserver-xorg-legacy gibt die Möglichkeit, das alte Verhalten wieder herzustellen.
Daß die Installation des Paketes allein das nicht bewirkt, sollte in der Paketbeschreibung deutlich zu lesen sein. Ist aber nicht, muß man erst in den Tiefen von man und web herausfinden.
Es könnte sein, daß einige legacy-Treiber xserver-xorg-legacy als Abhängigkeit haben und die Konfiguration beim Installieren selbst ändern.
Die Konfigurationsdatei /etc/X11/Xwrapper.config gab es früher auch schon, meine ich mich zu erinnern. Neu ist die Zeile needs_root_rights=yes.
xserver-xorg-legacy gibt die Möglichkeit, das alte Verhalten wieder herzustellen.
Daß die Installation des Paketes allein das nicht bewirkt, sollte in der Paketbeschreibung deutlich zu lesen sein. Ist aber nicht, muß man erst in den Tiefen von man und web herausfinden.
Es könnte sein, daß einige legacy-Treiber xserver-xorg-legacy als Abhängigkeit haben und die Konfiguration beim Installieren selbst ändern.
Die Konfigurationsdatei /etc/X11/Xwrapper.config gab es früher auch schon, meine ich mich zu erinnern. Neu ist die Zeile needs_root_rights=yes.
Der Sicherheitsgewinn ist der, daß kein Programm innerhalb von X ein weiteres X starten kann.Oder so rum: Mir ist nicht nicht klar, ob die Benutzung von ...legacy (im Falle das rootloses X aus welchem Grunde auch immer nicht funktioniert) irgendeinen Sicherheitsgewinn gegenüber dem händischen Setzen des SUID-Bits bringt.
Die Vernunft kann einem schon leidtun. Sie verliert eigentlich immer.
-
- Beiträge: 385
- Registriert: 16.06.2017 09:52:36
Re: xserver-xorg-legacy
Nach dort exakt dokumentierten Änderungen!tobo hat geschrieben:23.12.2018 19:39:01Ohne die Installation von libpam-systemd habe ich das auch noch nicht hinbekommen!? Hier wird allerdings das Gegenteil behauptet:
viewtopic.php?f=15&t=168996&hilit=libpam+systemd
Welches init-System bzw. Hauptsache: elogind wird gestartet? (Paket "elogind"+"libelogind0" ist natürlich ebenfalls erforderlich.)guennid hat geschrieben:23.12.2018 20:00:55Installation von libpam-elogind (devuan-ascii) hat nicht geholfen.
Also hier:
Code: Alles auswählen
user@hostname:~$ ps -eHo pid,pgid,sid,ppid,tty,user,ruser,time,comm
[...]
2334 2333 2333 1 ? root root 00:00:00 elogind
2531 2531 2531 1 tty1 root root 00:00:00 login
2554 2554 2531 2531 tty1 user user 00:00:00 bash
2602 2602 2531 2554 tty1 user user 00:00:00 startx
2624 2602 2531 2602 tty1 user user 00:00:00 xinit
2625 2625 2531 2624 tty1 user user 00:02:49 Xorg
2631 2631 2531 2624 tty1 user user 00:00:01 dwm
[...]
Code: Alles auswählen
user@hostname:~$ ll /usr/bin/X
lrwxrwxrwx 1 root root 4 Okt 31 17:58 /usr/bin/X -> Xorg
user@hostname:~$ ll /usr/bin/Xorg
-rwxr-xr-x 1 root root 274 Okt 31 17:58 /usr/bin/Xorg
user@hostname:~$ cat /usr/bin/Xorg
#!/bin/sh
#
# Execute Xorg.wrap if it exists otherwise execute Xorg directly.
# This allows distros to put the suid wrapper in a separate package.
basedir=/usr/lib/xorg
if [ -x "$basedir"/Xorg.wrap ]; then
exec "$basedir"/Xorg.wrap "$@"
else
exec "$basedir"/Xorg "$@"
fi
user@hostname:~$ ll /usr/lib/xorg/Xorg.wrap
ls: cannot access '/usr/lib/xorg/Xorg.wrap': No such file or directory
user@hostname:~$ ll /usr/lib/xorg/Xorg
-rwxr-xr-x 1 root root 2,4M Okt 31 17:58 /usr/lib/xorg/Xorg
Re: xserver-xorg-legacy
Plausibel nachvollziehbar, danke!.MartinV hat geschrieben:Der Sicherheitsgewinn ist der, daß kein Programm innerhalb von X ein weiteres X starten kann.
Neue Frage "(k)ein weiteres X". Meint du damit sowas wie weitere GUI-Bildschirme starten (bei openbox gibt's, wenn ich recht sehe, defaultmäßig deren vier)? Sowas nutze ich nicht, aber das ist meine Angelegenheit.
Grüße, Günther
Re: xserver-xorg-legacy
Init-System: Ich teste openrc. Und ich bin nicht besonders bewandert. elogind ist installiert und lässt sich aktivieren, ob er bereits beim Booten aktiviert wird, weiß ich nicht. Wie kann ich das feststellen? rcconf funktioniert da nicht mehr - richtig?
Da ich eh teste, würde ich es dann nochmal versuchen, diesen ...legacy in Gang zu kriegen. Obwohl - der Nutzen erscheint mir unter realen Bedingungen immer noch eher gering im Verhältnis zum Aufwand.
Grüße, Günther
Da ich eh teste, würde ich es dann nochmal versuchen, diesen ...legacy in Gang zu kriegen. Obwohl - der Nutzen erscheint mir unter realen Bedingungen immer noch eher gering im Verhältnis zum Aufwand.
Grüße, Günther
Re: xserver-xorg-legacy
Ich meine damit einen kompletten zweiten X Server auf einem anderen tty. Dort kann auch ein ganz anderer Desktop laufen. Das Wechseln ist, wie bei tty sonst auch, mit strg+alt+F1..F12.guennid hat geschrieben:24.12.2018 13:55:42Neue Frage "(k)ein weiteres X". Meint du damit sowas wie weitere GUI-Bildschirme starten (bei openbox gibt's, wenn ich recht sehe, defaultmäßig deren vier)? Sowas nutze ich nicht, aber das ist meine Angelegenheit.
Wenn X in X auf demselben tty gestartet wird, gibt es einen Crash. (Mit der X Option vt kann ein anderes tty definiert werden).
Die Vernunft kann einem schon leidtun. Sie verliert eigentlich immer.
Re: xserver-xorg-legacy
Ah ja, verstanden! Ich meine, das ging bisher nie bei mir. - Und ich hab's auch wie gesagt, nicht vermisst.hat geschrieben:Ich meine damit einen kompletten zweiten X Server auf einem anderen tty.
edit:
Und du hast recht, momentan, also ohne ...legacy und mit händisch gesetzten SUID-Bit für Xorg funktioniert, was mich eigentlich nie interessierte: Starten einer weiteren X-Sitzung auf einem anderen tty. Vorläufig fällt mir nicht ein, ob das für mich, der ich ausschließlich alleine an der Maschine sitze und auch allen meinen Familienmitgliedern vertraue, ein reales Sicherheitsrisiko bedeutet. Solange mich da niemand nachvollziehbar eines Schlechteren belehrt, werde ich mir die MÜhe doch nicht machen, erneut ...legacy auf der Maschine zu installieren und zu konfigurieren.
Interessanterweise funktioniert es auf einer anderen Stretch-Maschine, die ich irgendwann mal (zumindest vor Stretch) so konfiguriert hatte, dass der xserver, wie früher üblich auf tty7 läuft und mit sysvinit als Init-system und ebenfalls ohne ...legacy nicht, dass eine weitere X-Session auf einem anderen tty eröffnet werden kann - ist leider so lange her, dass ich nicht mehr nachvollziehen kann, wie ich das angestellt habe. Aber das ist vielleicht ein anderes Thema.
Grüße, Günther
Re: xserver-xorg-legacy
Alte Treiber fliegen irgendwann raus. Falls die Karte noch intakt ist und es liegt an einem fehlenden alten Treiber, könnte antix (auf Debian-Basis) einen Versuch wert sein. Das behält und unterstützt alte Treiber wesentlich länger.guennid hat geschrieben:23.12.2018 20:37:34Ziemlich altes Teil, aber wie gesagt: Ich besitze keine Maschine, bei der's funktioniert hätte.Code: Alles auswählen
VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 04)
Die Vernunft kann einem schon leidtun. Sie verliert eigentlich immer.
- jph
- Beiträge: 1049
- Registriert: 06.12.2015 15:06:07
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: Greven/Westf.
Re: xserver-xorg-legacy
Ich greife mal die Frage aus der Threaderöffnung auf:
Aktuelle Treiber kommen scheint’s mit fehlenden root-Rechten klar, so dass Xorg.wrap diese ggf. fallen lässt, aber diese uralten Closed-Source-Treiber scheinen die zu benötigen. Und Nvidia fasst diese Treiber nicht mehr an.
Die Fragen, die ihr im weiteren Verlauf des Threads aufgreift, sind i.W. die Motivation für rootless X und was dafür alles im Plumbing Layer angepasst werden musste.
Steht in der Paketbeschreibung: „This package provides a wrapper for the Xorg X server, which is necessary for legacy drivers and non-Linux kernels.“ Wenn ich schaue, welche Pakete davon abhängen, finde ich nur xserver-xorg-video-nvidia-legacy-304xx.
Aktuelle Treiber kommen scheint’s mit fehlenden root-Rechten klar, so dass Xorg.wrap diese ggf. fallen lässt, aber diese uralten Closed-Source-Treiber scheinen die zu benötigen. Und Nvidia fasst diese Treiber nicht mehr an.
Die Fragen, die ihr im weiteren Verlauf des Threads aufgreift, sind i.W. die Motivation für rootless X und was dafür alles im Plumbing Layer angepasst werden musste.
Re: xserver-xorg-legacy
rootless-x funktioniert mit genauso wenig. Der ist onboard eines TP T430, sollte also nicht so alt sein. Beide GraKas laufen mit xserver-xorg-video-intel aus stretch (einmal i386 und einmal amd64).
Grüße, Günther
Code: Alles auswählen
Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09)
Grüße, Günther
- jph
- Beiträge: 1049
- Registriert: 06.12.2015 15:06:07
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: Greven/Westf.
Re: xserver-xorg-legacy
Das ist interessant. Auf meinem T460s (s. viewtopic.php?f=26&t=171581) läuft rootless X mit dem gleichen Treiber.
Mein ausrangiertes X220 habe ich gerade leider nicht greifbar, um das nachzuprüfen.
Mein ausrangiertes X220 habe ich gerade leider nicht greifbar, um das nachzuprüfen.
Re: xserver-xorg-legacy
Korrektur:
Nachdem ich bei installiertem ...legacy in /etc/X11/Xwrapper.config die Zeile "needs_root_rights=yes" angefügt hatte, funktioniert X, ohne dass das SUID-Bit für /usr/lib/xorg/Xorg gesetzt würde, und zwar auf beiden Maschinen. Also für "rootless" halte ich das eigentlich nicht.
Der User kann auch weiterhin mehrere X-Sitzungen starten. (Ich hatte MartinV so verstanden, dass ...legacy das verhindert, zumindest, wenn nichts anderes als das u.a. in Xwrapper.config steht.)
IN der Xwrapper.config stehen lediglich die beiden Zeilen
Grüße, Günther
Nachdem ich bei installiertem ...legacy in /etc/X11/Xwrapper.config die Zeile "needs_root_rights=yes" angefügt hatte, funktioniert X, ohne dass das SUID-Bit für /usr/lib/xorg/Xorg gesetzt würde, und zwar auf beiden Maschinen. Also für "rootless" halte ich das eigentlich nicht.
Der User kann auch weiterhin mehrere X-Sitzungen starten. (Ich hatte MartinV so verstanden, dass ...legacy das verhindert, zumindest, wenn nichts anderes als das u.a. in Xwrapper.config steht.)
IN der Xwrapper.config stehen lediglich die beiden Zeilen
Code: Alles auswählen
allowed_users=console
needs_root_rights=yes
Zuletzt geändert von guennid am 27.12.2018 14:45:00, insgesamt 1-mal geändert.
Re: xserver-xorg-legacy
So habe ich mich selbst auch verstanden ... Das Starten von X sollte mit der config nur von Konsole aus möglich sein. Bist Du sicher, daß Du nicht irgendwo ein gesetztes suid-Bit vergessen hast?guennid hat geschrieben:26.12.2018 20:07:27Der User kann aber weiterhin mehrere X-Sitzungen starten. (Ich hatte MartinV so verstanden, dass ...legacy das verhindert, zumindest, wenn nichts anderes als das u.a. in Xwrapper.config steht.)
Die Vernunft kann einem schon leidtun. Sie verliert eigentlich immer.
Re: xserver-xorg-legacy
Ich bin mir meiner Überlegungen und Handlungen nie völlig sicher.
Bei diesen Experimenten erinnere ich nicht, selbst händisch irgendwo anders als bei /usr/lib/xorg/Xorg ein SUID-Bit gesetzt zu haben.
Der faktische Mehr-Nutzen von ...legacy gegenüber der SUID-Methode bleibt für mich nach deinem letzten Post weiterhin offen.
Grüße, Günther
Bei diesen Experimenten erinnere ich nicht, selbst händisch irgendwo anders als bei /usr/lib/xorg/Xorg ein SUID-Bit gesetzt zu haben.
Der faktische Mehr-Nutzen von ...legacy gegenüber der SUID-Methode bleibt für mich nach deinem letzten Post weiterhin offen.
Grüße, Günther