xserver-xorg-legacy

KDE, Gnome, Windowmanager, X11, Grafiktreiber und alles was dazu notwendig ist. Schau auch in den "Tipps und Tricks"-Bereich.
Antworten
guennid

xserver-xorg-legacy

Beitrag von guennid » 23.12.2018 19:27:41

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 :evil: ), der dann genau dies bewerkstelligt. Hier (stretch) tut er das jedenfalls nicht.

Grüße, Günther
Zuletzt geändert von guennid am 24.12.2018 12:08:55, insgesamt 2-mal geändert.

tobo
Beiträge: 1964
Registriert: 10.12.2008 10:51:41

Re: xserver-xorg-legacy

Beitrag von tobo » 23.12.2018 19:39:01

guennid hat geschrieben: ↑ zum Beitrag ↑
23.12.2018 19:27:41
Hier (stretch) tut er das jedenfalls nicht.
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

guennid

Re: xserver-xorg-legacy

Beitrag von guennid » 23.12.2018 20:00:55

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

Benutzeravatar
MartinV
Beiträge: 788
Registriert: 31.07.2015 19:38:52
Wohnort: Hyperion
Kontaktdaten:

Re: xserver-xorg-legacy

Beitrag von MartinV » 23.12.2018 20:05:02

Nach der Installation von Debianxserver-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:

Code: Alles auswählen

allowed_users=console
Das kannst Du ändern z.B. zu

Code: Alles auswählen

allowed_users=anybody
needs_root_rights=yes
Was genau geht bei Dir nicht?
Die Vernunft kann einem schon leidtun. Sie verliert eigentlich immer.

guennid

Re: xserver-xorg-legacy

Beitrag von guennid » 23.12.2018 20:10:12

MartinV hat geschrieben:Nach der Installation von Debian Debianxserver-xorg-legacy ist das suid-Bit eigentlich (?) gesetzt.
So etwa hatte ich das auch vermutet, war aber nicht. Neustart vonnöten?

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
MartinV hat geschrieben:Was genau geht bei dir nicht?
Rechner friert nach startx komplett ein. Nichts geht mehr.

Grüße, Günther

Benutzeravatar
MartinV
Beiträge: 788
Registriert: 31.07.2015 19:38:52
Wohnort: Hyperion
Kontaktdaten:

Re: xserver-xorg-legacy

Beitrag von MartinV » 23.12.2018 20:16:49

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:

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
Xorg.wrap hat das suid-bit.
Rechner friert nach startx komplett ein. Nichts geht mehr.
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?
Die Vernunft kann einem schon leidtun. Sie verliert eigentlich immer.

guennid

Re: xserver-xorg-legacy

Beitrag von guennid » 23.12.2018 20:37:34

Ich vermute Xorg.wrap kommt mit legacy. Hier ist es jedenfalls nach der Deinstallation nicht (mehr) vorhanden.

Code: Alles auswählen

VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 04)
Ziemlich altes Teil, aber wie gesagt: Ich besitze keine Maschine, bei der's funktioniert hätte. Belassen wir's dabei.

Grüße, Günther

guennid

Re: xserver-xorg-legacy (entfernt)

Beitrag von guennid » 24.12.2018 12:08:35

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:
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.
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?
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

Benutzeravatar
MartinV
Beiträge: 788
Registriert: 31.07.2015 19:38:52
Wohnort: Hyperion
Kontaktdaten:

Re: xserver-xorg-legacy

Beitrag von MartinV » 24.12.2018 12:27:42

guennid hat geschrieben: ↑ zum Beitrag ↑
24.12.2018 12:08:35
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?
Ich glaube eher, daß Xorg.wrap nur in der Konfigurationsdatei /etc/X11/Xwrapper.config nachschaut, ob es X mit root-Rechten starten soll.
Dafür die Zeile:

Code: Alles auswählen

needs_root_rights=yes
guennid hat geschrieben: ↑ zum Beitrag ↑
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".
Das ist eine Kompromißlösung, die ein bißchen Sicherheit geben soll.
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
guennid hat geschrieben: ↑ zum Beitrag ↑
24.12.2018 12:08:35
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.
Die Installation des Paketes allein ändert erst einmal nichts (soweit ich sehe). Damit X als root gestartet wird, brauchst Du die Konfiguration:

Code: Alles auswählen

allowed_users=console
needs_root_rights=yes
(Alle Angaben ohne Gewähr, stellenweise bin ich selbst etwas unsicher.)
Die Vernunft kann einem schon leidtun. Sie verliert eigentlich immer.

guennid

Re: xserver-xorg-legacy

Beitrag von guennid » 24.12.2018 12:42:06

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:
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.

Grüße, Günther

Benutzeravatar
MartinV
Beiträge: 788
Registriert: 31.07.2015 19:38:52
Wohnort: Hyperion
Kontaktdaten:

Re: xserver-xorg-legacy

Beitrag von MartinV » 24.12.2018 13:36:25

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.
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.
Der Sicherheitsgewinn ist der, daß kein Programm innerhalb von X ein weiteres X starten kann.
Die Vernunft kann einem schon leidtun. Sie verliert eigentlich immer.

RobertDebiannutzer
Beiträge: 385
Registriert: 16.06.2017 09:52:36

Re: xserver-xorg-legacy

Beitrag von RobertDebiannutzer » 24.12.2018 13:48:42

tobo hat geschrieben: ↑ zum Beitrag ↑
23.12.2018 19:39:01
guennid hat geschrieben: ↑ zum Beitrag ↑
23.12.2018 19:27:41
Hier (stretch) tut er das jedenfalls nicht.
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
Nach dort exakt dokumentierten Änderungen!
guennid hat geschrieben: ↑ zum Beitrag ↑
23.12.2018 20:00:55
Installation von libpam-elogind (devuan-ascii) hat nicht geholfen.
Welches init-System bzw. Hauptsache: elogind wird gestartet? (Paket "elogind"+"libelogind0" ist natürlich ebenfalls erforderlich.)
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
Wenn nicht startx genutzt wird, sondern ein Display-Manager wird es komplizierter, dazu kann ich dann nix mehr sagen. Soweit ich es in Erinnerung habe, sagt die offizielle Dokumentation, dass rootless X (auf offiziellem Weg) nur mit startx oder gdm möglich ist. Wie das mit einem anderen Weg aussieht - keine Ahnung.

guennid

Re: xserver-xorg-legacy

Beitrag von guennid » 24.12.2018 13:55:42

MartinV hat geschrieben:Der Sicherheitsgewinn ist der, daß kein Programm innerhalb von X ein weiteres X starten kann.
Plausibel nachvollziehbar, danke!.

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

guennid

Re: xserver-xorg-legacy

Beitrag von guennid » 24.12.2018 14:06:33

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

Benutzeravatar
MartinV
Beiträge: 788
Registriert: 31.07.2015 19:38:52
Wohnort: Hyperion
Kontaktdaten:

Re: xserver-xorg-legacy

Beitrag von MartinV » 24.12.2018 14:12:18

guennid hat geschrieben: ↑ zum Beitrag ↑
24.12.2018 13:55:42
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.
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.

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.

guennid

Re: xserver-xorg-legacy

Beitrag von guennid » 24.12.2018 15:04:13

hat geschrieben:Ich meine damit einen kompletten zweiten X Server auf einem anderen tty.
Ah ja, verstanden! Ich meine, das ging bisher nie bei mir. - Und ich hab's auch wie gesagt, nicht vermisst. :wink:

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. 8O :wink: Aber das ist vielleicht ein anderes Thema.

Grüße, Günther

Benutzeravatar
MartinV
Beiträge: 788
Registriert: 31.07.2015 19:38:52
Wohnort: Hyperion
Kontaktdaten:

Re: xserver-xorg-legacy

Beitrag von MartinV » 25.12.2018 21:01:54

guennid hat geschrieben: ↑ zum Beitrag ↑
23.12.2018 20:37:34

Code: Alles auswählen

VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 04)
Ziemlich altes Teil, aber wie gesagt: Ich besitze keine Maschine, bei der's funktioniert hätte.
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.
Die Vernunft kann einem schon leidtun. Sie verliert eigentlich immer.

Benutzeravatar
jph
Beiträge: 1049
Registriert: 06.12.2015 15:06:07
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Greven/Westf.

Re: xserver-xorg-legacy

Beitrag von jph » 26.12.2018 13:26:19

Ich greife mal die Frage aus der Threaderöffnung auf:
guennid hat geschrieben: ↑ zum Beitrag ↑
23.12.2018 19:27:41
Wozu ist dieses Teil eigentlich gut?
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.

guennid

Re: xserver-xorg-legacy

Beitrag von guennid » 26.12.2018 13:37:36

rootless-x funktioniert mit

Code: Alles auswählen

Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09)
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

Benutzeravatar
jph
Beiträge: 1049
Registriert: 06.12.2015 15:06:07
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Greven/Westf.

Re: xserver-xorg-legacy

Beitrag von jph » 26.12.2018 13:50:43

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.

guennid

Re: xserver-xorg-legacy

Beitrag von guennid » 26.12.2018 20:07:27

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

Code: Alles auswählen

allowed_users=console
needs_root_rights=yes
Grüße, Günther
Zuletzt geändert von guennid am 27.12.2018 14:45:00, insgesamt 1-mal geändert.

Benutzeravatar
MartinV
Beiträge: 788
Registriert: 31.07.2015 19:38:52
Wohnort: Hyperion
Kontaktdaten:

Re: xserver-xorg-legacy

Beitrag von MartinV » 26.12.2018 23:18:48

guennid hat geschrieben: ↑ zum Beitrag ↑
26.12.2018 20:07:27
Der 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.)
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?
Die Vernunft kann einem schon leidtun. Sie verliert eigentlich immer.

guennid

Re: xserver-xorg-legacy

Beitrag von guennid » 27.12.2018 09:25:28

Ich bin mir meiner Überlegungen und Handlungen nie völlig sicher. :wink:

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

Antworten