KDE autologin ohne displaymanager?

[clue]

Ich hab schon stundenlang gegoogelt, aber bin nicht wirklich fündig geworden.

Ich versuche zur Zeit KDE ohne SDDM oder einem anderen displaymanager zu starten.
Dazu habe ich wie hier viewtopic.php?f=27&t=154785&hilit=autologin&start=15 beschrieben in der Datei /etc/rc.local vor dem exit 0 den Eintrag su – clue startx -- vt5 hinzugefügt.

Leider kommt beim Systemstart dann diese Fehlermeldung:

Code: Alles auswählen

rc.local[504]: (EE) parse_vt_settings: Cannot open /dev/tty0 (Permission denied)

Ich kann trotzdem nach manueller Anmeldung auf einem beliebigen Terminal mit startx startkde in meine KDE session reinkommen.

Übrigens: Wenn ich nur startx eingebe, dann meckert er:

$DISPLAY not set or cannot connect to xserver

Aber mit startx startkde erhalte ich dann in meiner KDE session ne xTerm Konsole, die ich nicht wegklicken darf, sonst endet auch meine KDE session.

Ich würde gerne eine "normale" KDE session haben, ohne diese störende xTerm Konsole.

Könnt Ihr mir helfen?

[guennid]

startx als root probiert?

[NAB]

Ich dachte ja, ich hätte die Sache mit "Xorg ohne root" endlich verstanden, dank dieses Threads:
viewtopic.php?f=37&t=169124

Und nun kommst du, ich hab noch mal gegoogelt, stieß auf diesen Bugreport:
https://bugs.debian.org/cgi-bin/bugrepo ... bug=856351
und hab wieder so meine Zweifel.

Die Meldung "parse_vt_settings: Cannot open /dev/tty0 (Permission denied)" scheint damit zu tun zu haben, dass die Rechte von /dev/tty* nicht richtig gesetzt sind. Ich hab keine Ahnung, was die setzt, aber es sieht so aus, als ob die noch nicht stimmen, wenn deine rc.local ausgeführt wird - später geht es ja.

Deine rc.local wird also zu früh ausgeführt. Eventuell hilft ein sleep 10 (hässliche Lösung), sonst müsstest du dir eine Systemd-Unit basteln.

Woher der XTerm kommt, weiß ich aber auch nicht. Kann es sein, dass du irgendwo eine .xinitrc oder .xsession rumliegen hast, die komische Einstellungen enthält? Passiert das auch mit einem anderen User?

[c1ue]

Komisch, momentan startet der X-server auch mit startx als normaler user. Keine Ahnung ob da nicht doch ein timing Problem ist, wie NAB vermutet hat.

Also: startx geht sowohl als root als auch als normaler user, als auch mit gerade frisch angelegtem user.
Mit startx lande ich aber in openbox, nicht in KDE. KDE geht momentan bei mir nur mit startx startkde, wobei ich dann dieses dämliche x-Terminal bekomme, welches ich nicht wegklicken darf.

Ich dachte ja, ich hätte die Sache mit "Xorg ohne root" endlich verstanden, dank dieses Threads:
viewtopic.php?f=37&t=169124

Und nun kommst du, ich hab noch mal gegoogelt, stieß auf diesen Bugreport:
https://bugs.debian.org/cgi-bin/bugrepo ... bug=856351
und hab wieder so meine Zweifel.

Genau so war es auch bei mir: Mit SDDM lief der X-server die ganze Zeit als root!

Die Meldung "parse_vt_settings: Cannot open /dev/tty0 (Permission denied)" scheint damit zu tun zu haben, dass die Rechte von /dev/tty* nicht richtig gesetzt sind. Ich hab keine Ahnung, was die setzt, aber es sieht so aus, als ob die noch nicht stimmen, wenn deine rc.local ausgeführt wird - später geht es ja.

Deine rc.local wird also zu früh ausgeführt. Eventuell hilft ein sleep 10 (hässliche Lösung), sonst müsstest du dir eine Systemd-Unit basteln.

Ja, ich vermute, dass da wohl leider was dran sein könnte. Aber ein sleep 10 ist eigentlich kontraproduktiv, da ich mit Verzicht auf SDDM ja eigentlich meine boot Zeit verkürzen wollte.

Hier habe ich einen möglichen workaround gefunden. Aber ich weiß nicht, ob ich mir damit nicht eine riesen Sicherheitslücke aufreiße:

https://askubuntu.com/questions/781207/ ... boot-fails

Woher der XTerm kommt, weiß ich aber auch nicht. Kann es sein, dass du irgendwo eine .xinitrc oder .xsession rumliegen hast, die komische Einstellungen enthält? Passiert das auch mit einem anderen User?

Ja, das passiert auch mit einem gerade frisch auf der Kommandozeile angelegten user. Irgendwie müsste bei systemd das default target und irgendwo auch die default session eingetragen werden können, damit bei startx nicht openbox, sondern KDE kommt.

Ach so, falls sich jemand wundert, weshalb ich mit einem neuen Benutzernamen schreibe: Ich hab mich gestern selbst ausgesperrt, als ich meine Mail-Adresse ändern wollte. Ist echt ärgerlich, dass die board software keinen timeout hat, sofern die neue Mail-Adresse nicht nach X Stunden bestätigt worden ist.

[KP97]

Hier nochmal meine alten Beiträge, im ersten Link bitte die Einträge von TomL ignorieren, die beruhen auf einem Mißverständnis:
viewtopic.php?f=29&t=161174&hilit=autostart
und hier noch etwas älter:
viewtopic.php?f=27&t=154785&hilit=autologin&start=15

[NAB]

Komisch, momentan startet der X-server auch mit startx als normaler user. Keine Ahnung ob da nicht doch ein timing Problem ist, wie NAB vermutet hat.

Meine Vermutung war auf den Start in der rc.local beschränkt. Wenn startx mal geht und mal nicht, nachdem der Boot abgeschlossen ist (du dich also einloggen kannst), würde ich eher auf Magie oder Sonnenwinde tippen.

(Nach der Lektüre des Bugreports würde ich auch vermuten, dass es vom installierten (aber nicht aktivierten) Displaymanager abhängen könnte)

Also: startx geht sowohl als root als auch als normaler user, als auch mit gerade frisch angelegtem user.
Mit startx lande ich aber in openbox,

Es ist mir immer noch ein Schleier, wo Debian den Default-Desktop des jeweiligen Users für startx versteckt, aber eigentlich solltest du ihn in ~/.xsession überschreiben können. Hier:
https://unix.stackexchange.com/question ... -change-it
ist das zwar Englisch aber recht liebevoll erklärt.

Und wirf mal einen Blick in die ~/.dmrc
Bei meinem letzten Versuch (vor Jahren) wurde die nur von Displaymanager ausgewertet, aber vielleicht hat sich da was geändert.

nicht in KDE. KDE geht momentan bei mir nur mit startx startkde, wobei ich dann dieses dämliche x-Terminal bekomme, welches ich nicht wegklicken darf.

Das ist mir weiterhin ein Rätsel. Der XTerminal ist eigentlich der Default, den du aber eigentlich mit "startkde" überschreibst. Und das "startkde" nimmt er wahr, sonst würde er ja openbox starten und nicht KDE. Eventuell kannst du dieses Verhalten auch in der ~/.xsession überschreiben.

Genau so war es auch bei mir: Mit SDDM lief der X-server die ganze Zeit als root!

Eben ... und ich hab mich gewundert, warum es bei anderen Leuten anders ist. Anscheinend klappt "Xorg ohne root" nur mit GDM. Die Idee ist zwar wirr, aber vielleicht hilft es, wenn du den GDM installierst und danach wieder deinstallierst.

Theoretisch könntest du GDM auch installiert lassen, aber nicht starten:
systemctl disable display-manager.service

Hier habe ich einen möglichen workaround gefunden. Aber ich weiß nicht, ob ich mir damit nicht eine riesen Sicherheitslücke aufreiße:

https://askubuntu.com/questions/781207/ ... boot-fails

Du könntest vorallem erst mal gucken, was mit deinen /dev/tty los ist. Mal
ls -la /dev/tty*
angucken.
Und in die rc.local mal
ls -la /dev/tty* > /root/debug.txt
reinschreiben.
Das setfacl finde ich besonders hässlich, weil man es nicht gleich sieht. Ein
chown root:clue /dev/tty0
dürfte vermutlich reichen. Insbesondere solltest du gucken, wie die Berechtigungen aussehen, wenn das System fertig gebootet hat. Wenn du diese Berechtigungen genau so schon vorher in der rc.local setzt, kann das ja nicht allzu schädlich sein.

[mludwig]

Den Standard-Desktop kann man doch mit dem alternatives-System von Debian festlegen.
In /etc/alternatives gibt es Symlinks für x-session-manager und x-window-manager

Code: Alles auswählen

#update-alternatives --list x-session-manager
/usr/bin/gnome-session
/usr/bin/openbox-session
/usr/bin/startkde

#ls -l /etc/alternatives/x-session-manager
lrwxrwxrwx 1 root root 22 Nov 15  2016 /etc/alternatives/x-session-manager -> /usr/bin/gnome-session

update-alternatives --set <Name> <Pfad>

x-window-manager gibt es bei mir auch noch.
Damit werden dann für alle! Nutzer die Standards gesetzt.

[KP97]

Nachdem ich ja meine alten Beiträge vorgekramt habe, war das ein Anlaß, nochmal nachzuprüfen, ob die Vorschläge alle noch funktionieren.
Leider ist das nicht mehr so.

1. Der xstart.service funktioniert nicht mehr mit der Angabe User=
Lt. manpages und auch Hinweisen im Netz kann man das aber so machen, einen Fehler kann ich nicht finden.
Lasse ich die Zeile weg, startet systemd den Xserver, aber als root. Das wollen wir ja nicht.
Als ich das in 2016 geschrieben habe, funktionierte das aber genau so, man sieht ja auch die Logausgabe.
K.A. was da falsch läuft, kann den Fehler nicht entdecken.

2. Zu rc.local
Auch hier kann man den User mit su - user nicht mehr vorgeben. Ohne diese Angabe funktioniert es wieder, aber ebenfalls als root, da der Service ja root gehört.
Auch keine Option. Zu den falschen tty-Berechtigungen hatte ich mal in /etc/udev/rules.d/50-udev-default-rules
die Berechtigung auf 666 erhöht:

Code: Alles auswählen

SUBSYSTEM=="tty", KERNEL=="tty", GROUP="tty", MODE="0666"
SUBSYSTEM=="tty", KERNEL=="tty[0-9]*", GROUP="tty", MODE="0666"

Damit sollte der Fehler weg sein.

Der einzige Ablauf, den ich für ein autologin nutze und der auch so schon die ganze Zeit funktioniert, ist dieser:
1. Als User eine .bash_profile anlegen mit diesem Inhalt

Code: Alles auswählen

if [ -z "$DISPLAY" ] && [ $(tty) == /dev/tty1 ]; then
   startxfce4 -- vt1 &> /dev/null
fi

Da ich Xfce nutze, steht dort startxfce4. Man kann auch z.B. startkde oder nur startx eintragen.

2. In /etc/systemd/system einen Ordner namens getty@tty1.service.d erstellen.
Darin eine Datei namens autologin.conf mit diesem Inhalt

Code: Alles auswählen

[Service]
ExecStart=
ExecStart=-/sbin/agetty --autologin user --noclear %I
Type=idle

"user" mit dem jeweiligen Usernamen ersetzen.
Nun noch ein

Code: Alles auswählen

systemctl enable getty@tty1.service.d

Anschließend sollte ein automatisches Login mitsamt Desktop erfolgen.

Aber wie schon erwähnt, nur für User, die den Rechner allein nutzen.

[guennid]

Nun gib dem xserver doch einfach sein SUID-Bit und Ruh ist. Das war hier 15 Jahjre lang notwendig. Warum da 'ne halbe Stunde vor Betriebsschluss so'n Bohai drum gemacht wird, versteh' ich sowieso nicht so recht.

Und so wenig wie man einen Login-Manager benötigt, so wenig benötigt man KDE.

[NAB]

Den Standard-Desktop kann man doch mit dem alternatives-System von Debian festlegen.

Stimmt ... aber die Frage ist, was startx auswertet. (Bin grad zu faul das auszuprobieren)

1. Der xstart.service funktioniert nicht mehr mit der Angabe User=
Lt. manpages und auch Hinweisen im Netz kann man das aber so machen, einen Fehler kann ich nicht finden.

Doch, User= sollte seitens Systemd weiterhin funktionieren. Das muss an was anderem scheitern (z.B. an falschen TTY-Rechten).

2. Zu rc.local
Auch hier kann man den User mit su - user nicht mehr vorgeben.

Doch, das geht. Aber ich sehe gerade, dass du im anderen Thread kein -c benutzt. Richtig wäre:
su - user -c startx
Ging das jemals ohne -c?
Andererseits warnt man su, dass man mit -c keine interaktiven Programme starten soll. Wiederum andererseits funktioniert "nano" bei mir so doch. Der Emacs öffnet auch ein Fenster, verhält sich dann aber sehr komisch, als sei ihm die Tastaturbelegung abhanden gekommen.
Eventuell ist "sudo" hier die bessere Wahl.

Und deine Udev-Regel setzt jedes TTY auf 666, oder? Ist das nicht etwas gewagt? Kann dann nicht "jeder" jede Eingabe belauschen?

Weißt du, wie deine "einzig noch funktionierende Lösung" die Rechte von tty1 setzt?

Ich verstehe nicht so ganz, wieweit Systemd die TTYs unter seiner Fuchtel hat und wer für das Setzen der richtigen Rechte zuständig ist. Der GDM muss das ja auch irgendwie hinbekommen ...

[KP97]

@NAB
Ich habe gestern noch mal einiges ausprobiert.
Du schreibst

su - user -c startx
Ging das jemals ohne -c?

Ja, selbst wenn ich den Befehl mit -c eintrage, funktioniert es als User trotzdem nicht.

Und deine Udev-Regel setzt jedes TTY auf 666, oder? Ist das nicht etwas gewagt? Kann dann nicht "jeder" jede Eingabe belauschen?

Na ja, ich hock' hier alleine, da kann man das mal vernachlässigen.

Weißt du, wie deine "einzig noch funktionierende Lösung" die Rechte von tty1 setzt?

So: crw-rw-rw- 1 root tty 4, 7 Mär 28 10:18 tty
Der Service wird weiterhin nicht als User ausgeführt, auch ohne die geänderte rule, also mit reinem Standard. Wie gesagt, als root ok, als User leider nicht.
Das ärgert mich, daß ich den Fehler nicht sehe. Aber mehr will ich jetzt nicht mehr herumschrauben.
Ob es bei anderen Anwendern/Systemen funktioniert, weiß ich nicht. Evtl. mag das ja mal jemand testen.

Nodm hat nun auch einen eigenen Service und funktioniert auch, falls den jemand nutzen möchte.

[NAB]

Ja, selbst wenn ich den Befehl mit -c eintrage, funktioniert es als User trotzdem nicht.

Ich vermute, das wird mit den Rechten von /dev/tty* zu tun haben. Die könnte man sich in der rc.local natürlich auch setzen. Grob und ungetestet aus deinen Beispielen zusammenkopiert so:

chown root:user /dev/tty1
su - user -c startxfce4 -- vt1

Fragt sich nur, ob was anderes (Systemd?) danach dazwischenschießt und die Rechte noch mal verstellt.

Na ja, ich hock' hier alleine, da kann man das mal vernachlässigen.

Naja ... und jeder Trojaner, den du startest, könnte dein root-Passwort auf dem anderen tty mitlauschen ...

So: crw-rw-rw- 1 root tty 4, 7 Mär 28 10:18 tty

Sieht das für alle TTYs gleich aus? Das ist /dev/tty und du benutzt /dev/tty1
Ich hätte root:benutzer erwartet statt root:tty

nodm kannte ich noch nicht. Der scheint alles zu machen, was notwendig ist, inklusive tty zu reservieren und eine PAM-Session zu öffnen:
https://github.com/spanezz/nodm/
Den würde ich an clues Stelle zuerst ausprobieren.

[c1ue]

Ging das jemals ohne -c?
Andererseits warnt man su, dass man mit -c keine interaktiven Programme starten soll. Wiederum andererseits funktioniert "nano" bei mir so doch. Der Emacs öffnet auch ein Fenster, verhält sich dann aber sehr komisch, als sei ihm die Tastaturbelegung abhanden gekommen.

Also wenn ich meine KDE session mit startx startkde starte, dann kann ich zum Beispiel Firefox nicht mehr unter einem anderen hostname mit firejail laufen lassen, es kommt der schon erwähnte DISPLAY error.

Reading profile /etc/firejail/firefox.profile
Reading profile /etc/firejail/disable-common.inc
Reading profile /etc/firejail/disable-programs.inc
Reading profile /etc/firejail/disable-devel.inc
Reading profile /etc/firejail/whitelist-common.inc
Parent pid 1430, child pid 1431
Blacklist violations are logged to syslog
Child process initialized
No protocol specified
Unable to init server: Verbindung ist gescheitert:Verbindungsaufbau abgelehnt
Error: cannot open display: :0

Parent is shutting down, bye...

Lasse ich hingegen den künstlichen hostname weg, funktioniert es, als wenn ich SDDM weiterhin benutzen würde. Meine Vermutung ist immer noch diese dämliche DISPLAY Geschichte (s. Eingangsbeitrag).

Eventuell ist "sudo" hier die bessere Wahl.

Laufen dann nicht ALLE meine Programme, die ich unter KDE starte, als root - also auch der Firefox?

Und deine Udev-Regel setzt jedes TTY auf 666, oder? Ist das nicht etwas gewagt? Kann dann nicht "jeder" jede Eingabe belauschen?

Weißt du, wie deine "einzig noch funktionierende Lösung" die Rechte von tty1 setzt?

Ich verstehe nicht so ganz, wieweit Systemd die TTYs unter seiner Fuchtel hat und wer für das Setzen der richtigen Rechte zuständig ist. Der GDM muss das ja auch irgendwie hinbekommen ...

Also jetzt, wo ich mich als user eingeloggt habe und meine startx startkde session am laufen habe, sagt ls -la /dev/tty*:

crw-rw-rw- 1 root tty     5,  0 Mär 28 10:37 /dev/tty
crw--w---- 1 root tty     4,  0 Mär 28 10:35 /dev/tty0
crw--w---- 1 root tty     4,  1 Mär 28 10:36 /dev/tty1
crw------- 1 clue tty     4,  2 Mär 28 10:36 /dev/tty2
crw--w---- 1 root tty     4, 20 Mär 28 10:35 /dev/tty20
crw--w---- 1 root tty     4, 21 Mär 28 10:35 /dev/tty21

Es sind also erwartungsgemäß alle root, bis auf tty2, auf dem ich mich ja eingeloggt habe. Wenn ich nicht (mehr) eingeloggt bin, gehören alle wieder root.


Nun bin ich der Anleitung von KP97 gefolgt und habe folgendes getan (ich will meine session auf tty2 und nicht tty1 haben):

1. Die .bash_profile angelegt mit folgendem Inhalt:

Code: Alles auswählen

if [ -z "$DISPLAY" ] && [ $(tty) == /dev/tty2 ]; then
   startkde -- vt2 &
fi

2. mkdir /etc/systemd/system/getty@tty2.service.d

3. Dann im besagten Ordner eine autologin.conf angelegt mit folgendem Inhalt:

Code: Alles auswählen

[Service]
ExecStart=
ExecStart=-/sbin/agetty --autologin user --noclear %I
Type=idle

4. systemctl enable getty@tty2.service.d

5. Nun zeigt systemctl status getty@tty2.service.d das hier an:

Code: Alles auswählen

● getty@tty2.service.d.service - Getty on tty2.service.d 
  Loaded: loaded (/lib/systemd/system/getty@.service; enabled; vendor preset: enabled) 
  Active: active (running) since Thu 2018-03-29 12:34:03 CEST; 3s ago 
    Docs: man:agetty(8) 
          man:systemd-getty-generator(8) 
          http://0pointer.de/blog/projects/serial-console.html 
Main PID: 2081 (agetty) 
   Tasks: 1 (limit: 4915) 
  CGroup: /system.slice/system-getty.slice/getty@tty2.service.d.service 
          └─2081 /sbin/agetty --noclear tty2.service.d vt220 

Mär 29 12:34:03 officepc systemd[1]: Started Getty on tty2.service.d. 
Mär 29 12:34:03 officepc agetty[2081]: /dev/tty2.service.d: cannot open as standard input: No such file or directory

Reboot gemacht und folgende 2 Probleme:

1. Der bleibt nach dem booten einfach auf tty1 stehen und zeigt nur den login prompt. Ich kann dann z.B. auf tty3 oder eine andere tty wechseln, nur startet der nicht standardmäßig mein KDE, bis ich nicht manuell auf tty2 wechsle. Erst dann loggt er mich automatisch ein und möchte KDE starten.
Wie kann ich es so einstellen, dass er nach dem booten gleich auf tty2 springt, mich einloggt & KDE startet?

2. StartKDE geht weiterhin nicht ohne ein vorhergehendes startx:

$Display is not set or cannot connect to x server

Mit startx startkde erhalte ich aber wieder diese lästige x-Term-Konsole, die ich nicht wegklicken darf.

Wie kann ich denn mal mein display richtig setzen, so dass ich kein startx startkde mehr benötige sondern nur startkde?

nodm kannte ich noch nicht. Der scheint alles zu machen, was notwendig ist, inklusive tty zu reservieren und eine PAM-Session zu öffnen:
https://github.com/spanezz/nodm/
Den würde ich an clues Stelle zuerst ausprobieren.

Das mache ich als nächstes. Doch da steht was von Sicherheitslücken, die man sich damit aufreißt. Darum nur als letzte Möglichkeit. Und wir sind ja schon fast am Ziel mit K97‘s Methode.

Oh ja, und mein Xorg läuft jetzt tatsächlich als clue und nicht mehr als root

[MartinV]

[über nodm:] Das mache ich als nächstes. Doch da steht was von Sicherheitslücken, die man sich damit aufreißt.

Die Sicherheitslücke ist "Einloggen ohne Paßwortabfrage". Aber genau das willst Du doch?

Mit startx startkde erhalte ich aber wieder diese lästige x-Term-Konsole, die ich nicht wegklicken darf.

Du könntest "xinit startkde" ausprobieren. startx macht im wesentlichen genau das. Ggf. mußt Du Dich bei xinit noch selbst um das Erzeugen von Cookies kümmern, oder auf Cookies verzichten.

[guennid]

@KP97
Ich stimme zu, das die Singularität des Benutzers (auf die der TE leider nicht eingeht) eine wichtige Voaussetzung ist, aber dies mal vorausgesetzt: Ist das ganze dann nicht 'ne ziemlich alberne Diskussion?

Antwort gerne auch per PN.

[NAB]

Error: cannot open display: :0

Heißt dein Display denn überhaupt :0? Was sagt denn
echo $DISPLAY

Und firejail habe ich mir nie näher angeguckt ... wechselt das vielleicht den Benutzernamen? Darf es dann noch dein Display benutzen?

Laufen dann nicht ALLE meine Programme, die ich unter KDE starte, als root - also auch der Firefox?

Wenn du sudo richtig benutzt, dann nicht
sudo -u clue /usr/bin/startkde

crw------- 1 clue tty     4,  2 Mär 28 10:36 /dev/tty2

Stimmt, das ist wohl der Punkt, auf den es ankommt.

Wie kann ich es so einstellen, dass er nach dem booten gleich auf tty2 springt, mich einloggt & KDE startet?

Ich würde erwarten, dass man das irgendwo in /etc/systemd/logind.conf einstellen kann, aber ich find da nix.
In der rc.local könntest du es mit einem:
chvt 2
versuchen, aber da fragt sich wieder, wann die ausgeführt wird und ob da nicht etwas dazwischenschießt. Eventuell kann man es in die Systemd-Unit reinquetschen, als ExecStartPre=/bin/chvt 2
aber ich bin mir völlig unklar über die Nebenwirkungen.

[KP97]

Also, ich meine mich zu erinnern, daß der getty@tty2 Service separat mit

Code: Alles auswählen

systemctl enable getty@tty2.service

gestartet werden muß.
Erst dann steht er beim Booten zur Verfügung und kann als autologin genutzt werden.
Die Berechtigungen für tty werden durch udev vergeben, das ja mittlerweile Teil von systemd ist. Man kann das wohl nicht trennen. An anderer Stelle finde ich auch nichts, das hat @NAB ja auch schon festgestellt.
Für diesen Ablauf ist aber ein Minimum von 664 nötig, sonst hat das tty für das autologin keine ausreichenden Rechte.
Mit Mode 664 sieht es dann so aus:

crw-rw-r-- 1 root tty 5, 0 Mär 29 17:39 tty
crw-rw-r-- 1 root tty 4, 0 Mär 29 17:39 tty0
crw------- 1 MB tty 4, 1 Mär 29 17:39 tty1
crw-rw-r-- 1 root tty 4, 10 Mär 29 17:39 tty10

Mein User ist MB, alles andere gehört root.
Sicherheitslücke? Ich weiß es nicht, wie gesagt, bin ich hier allein unterwegs.
Bei einem professionellen Einsatz in einem RZ würde man das natürlich nicht machen, keine Frage.

Mit meinem selbst erstellten xstart.service habe ich gestern noch eine Besonderheit festgestellt.
Die Zeile User=MB funktioniert, wenn ich dem Startbefehl ein Plus oder minus voranstelle.
ExecStart=+/usr/bin/startxfce4
ExecStart=-/usr/bin/startxfce4
Beide Male ist der Servicestatus grün, aber
mit dem Plus startet der User nobody
mit dem Minus wird startxfce4 nicht ausgeführt, der Service ist aber grün. Der Ablauf bleibt auf der Konsole stehen mit der Anmeldung des Users.
Ehrlich gesagt, bin ich aus der manpage aber nicht so recht schlau geworden.
Da es ja mal funktioniert hat, tippe ich auf eine Änderung in systemd, da ist ja nun seit 2016 jede Menge passiert.

@Günther
Ich sehe das als sportliche Herausforderung, also nichts, was man unbedingt braucht.

[NAB]

crw-rw-r-- 1 root tty 5, 0 Mär 29 17:39 tty
crw-rw-r-- 1 root tty 4, 0 Mär 29 17:39 tty0
crw------- 1 MB tty 4, 1 Mär 29 17:39 tty1
crw-rw-r-- 1 root tty 4, 10 Mär 29 17:39 tty10

Mein User ist MB, alles andere gehört root.
Sicherheitslücke? Ich weiß es nicht,

Die Sicherheitslücke, die ich sehe, ist das "r" für "alle", also die 4 vom 664. Warum brauchst du die? Bei mir sehen alle TTYs so aus:
crw--w---- 1 root tty
Wenn ich mich jetzt aber auf TTY1 anmelde, passiert das:
crw------- 1 nab tty
(ohne das ich dran rumgeschraubt hätte, standard Debian)
Ich vermute, das macht der tty1.service, in den du dich einklinkst. Ich wüsste nicht, warum du die udev-Rechte noch zusätzlich verändern solltest.

Die Zeile User=MB funktioniert, wenn ich dem Startbefehl ein Plus oder minus voranstelle.
ExecStart=+/usr/bin/startxfce4
ExecStart=-/usr/bin/startxfce4
Beide Male ist der Servicestatus grün, aber
mit dem Plus startet der User nobody
mit dem Minus wird startxfce4 nicht ausgeführt, der Service ist aber grün. Der Ablauf bleibt auf der Konsole stehen mit der Anmeldung des Users.

Dein Systemd ist kaputt
Mit Plus davor sollte die Zeile als "root" gestartet werden, nicht als "nobody".
Mit Minus davor sollte die Zeile ganz normal gestartet werden, aber Systemd ignoriert den Rückgabewert. Dementsprechend gibt's wohl ne Fehlermeldung, die Systemd ignortiert und meint, der Service läuft fein.

[c1ue]

Error: cannot open display: :0

Heißt dein Display denn überhaupt :0? Was sagt denn
echo $DISPLAY

Das sagt bei mir ganz genau:

echo $DISPLAY
:0

Und firejail habe ich mir nie näher angeguckt ... wechselt das vielleicht den Benutzernamen? Darf es dann noch dein Display benutzen?

Eben jenes ist eine gute Frage. Ich kann nur sagen, dass wenn ich "normal" über SDDM starte, ich auch meinen hostname spoofen kann, wie ich will. Aber mit startx startkde gehts merkwürdigster Weise nicht mehr.

Was mir jetzt momentan primär fehlt, ist das Ding mit dem DISPLAY. Was muss ich dem denn sagen, dass er das ohne dieses blöde startx vorweg macht? Irgendwas mit export display?

Also, ich meine mich zu erinnern, daß der getty@tty2 Service separat mit

Code: Alles auswählen

systemctl enable getty@tty2.service

gestartet werden muß.
Erst dann steht er beim Booten zur Verfügung und kann als autologin genutzt werden.

Jup, hab ich auch alles so gemacht, wie Du es geschrieben hast, nur eben statt auf tty1 bin ich auf tty2 gegangen. Es klemmt momentan nur an den beiden beschriebenen Problemen:

1. Er wechselt nicht automatisch auf tty2, um meine KDE session hochzufahren, sondern ich muss erst manuell auf tty2 wechseln.
2. Es wird noch immer ein startx benötigt.


Das mit dem xinit startkde probier ich mal aus und gib dann Rückmeldung.

EDIT

Jo, habs getestet: xinit startkde bewirkt das selbe wie startx startkde - beide zaubern eine lästige x-Term-Konsole auf den Desktop.

[NAB]

Eben jenes ist eine gute Frage. Ich kann nur sagen, dass wenn ich "normal" über SDDM starte, ich auch meinen hostname spoofen kann, wie ich will. Aber mit startx startkde gehts merkwürdigster Weise nicht mehr.

hmm ... wenn DISPLAY :1 vorhanden ist (sonst hättest du ja kein X), kann es eigentlich nur ein Berechtigungsproblem sein. Probier doch mal ein

Code: Alles auswählen

xhost + local:

als normaler User.

[MartinV]

Das mit dem xinit startkde probier ich mal aus und gib dann Rückmeldung.

EDIT

Jo, habs getestet: xinit startkde bewirkt das selbe wie startx startkde - beide zaubern eine lästige x-Term-Konsole auf den Desktop.

Hast Du eine Datei ~/.xinitrc ? Ich vermute, nein. Erzeuge sie mit lediglich einer Zeile Inhalt: startkde
Dann sollten sowohl startx als auch xinit den Inhalt von ~/.xinitrc ausführen, ohne ein xterm aufzurufen.

[c1ue]

Probier doch mal ein

Code: Alles auswählen

xhost + local:

als normaler User.

Habs auf der tty3 mal eingegeben. Ergebnis:

xhosts: unable to open display ""

Hast Du eine Datei ~/.xinitrc ? Ich vermute, nein. Erzeuge sie mit lediglich einer Zeile Inhalt: startkde
Dann sollten sowohl startx als auch xinit den Inhalt von ~/.xinitrc ausführen, ohne ein xterm aufzurufen.

Ja, hab ich jetzt gemacht: Aber leider unverändert.

Dann habe ich noch nodm installiert und danach auf https://wiki.debianforum.de/Nodm folgendes gelesen:

Ab Debian 9 (Stretch) ist zu überlegen, ob man nicht doch den Displaymanager der Desktopumgebung entsprechend konfiguriert und auf nodm verzichtet. Denn von nodm, wird der X-Server mit Rootrechten gestartet. Wohingegen GNOME/GDM3 den X-Server unter der eigenen UID, mit eingeschränkten Rechten startet.

Nunja... nachdem es wohl noch größerer Umbauten am System bedürfen könnte als bisher angenommen, kehre ich nun doch reumütig wieder zu SDDM zurück. Ist zwar schade, aber ich muss mich wohl geschlagen geben.

Ich danke Euch allen vielmals für Eure Mühe und Unterstützung

[NAB]

Habs auf der tty3 mal eingegeben.

Upps, das war ein Missverständnis. Du müsstest KDE starten, dort ein Terminal öffnen (der läuft ja schon *hüstel*) und dort:
xhost + local:
eingeben. Und dann dein Firejail starten.

Der Benutzer auf tty3 weiß ja gar nicht, dass auf tty2 ein X-Server läuft, darum funktioniert xhost dort nicht.

[c1ue]

Habs auf der tty3 mal eingegeben.

Upps, das war ein Missverständnis. Du müsstest KDE starten, dort ein Terminal öffnen (der läuft ja schon *hüstel*) und dort:
xhost + local:
eingeben. Und dann dein Firejail starten.

Der Benutzer auf tty3 weiß ja gar nicht, dass auf tty2 ein X-Server läuft, darum funktioniert xhost dort nicht.

Ok, also im KDE-Terminal xhost + local eingegeben:

xhost: bad hostname "local"

[detix]

Hab mich auch mal daran versucht ‒ also Autologin, X-start und Autoumschalten auf irgendeinem tty.
tty1 bleibt aber auch hierbei unbenutzbar, schlecht falls das stört..., falls nicht:

(kopieren der Datei /lib/systemd/system/getty@.service nach und als /etc/systemd/system/getty.target.wants/getty@tty2.service)
Edith: passt so nur für jessie, nicht für buster... das besteht auf Symlinks in getty.target.wants, für beide gilt aber:
kopieren der Datei /lib/systemd/system/getty@.service nach /etc/systemd/system/ und von dort aus verlinken:

Code: Alles auswählen

cd /etc/systemd/system
mkdir getty.target.wants
ln -rs getty@.service getty.target.wants/getty@tty2.service

Benennung nach gewünschtem tty, für zB tty4 demnach: getty@tty4.service
Änderung in dieser Datei:

ExecStart=-/sbin/agetty...
ersetzen durch:
ExecStart=-/sbin/agetty --autologin dein_username --noclear %I $TERM

Damit sollte der Autologin aufs entsprechende tty schon erledigt sein.
Um X zu starten dann noch die Datei /etc/skel/.profile nach $HOME kopieren und für zB tty2 dies hinzufügen:

Code: Alles auswählen

if [ -z "$DISPLAY" ] && [ $(tty) == /dev/tty2 ]; then
  startx
fi

Nur falls neben KDE noch andere Desktops installiert sind, dann den entsprechenden Startbefehl in eine Datei $HOME/.xinitrc schreiben:

Code: Alles auswählen

echo startkde >$HOME/.xinitrc
# oder für zB xfce4:
echo startxfce4 >$HOME/.xinitrc

Damit funktioniert das hier, ein Problem möchte ich aber bei einem anderen tty als tty1 nicht verschweigen:
meine NVidia Grafikkarte meint dann, das es opengl2 nicht finden kann, Plasma startet damit nicht und X läuft nur in VGA Auflösung!
Abhilfe schafft aber das Erstellen einer /etc/X11/xorg.conf mit Hilfe von (leider deprecated) nvidia-xconfig