Warum setzt sudo -i nicht XDG_RUNTIME_DIR für den Zielbenutzer?

XDG_RUNTIME_DIRist notwendig, um systemctl --userzu arbeiten.

Ich habe Ubuntu Server 16.04 eingerichtet, um systemd Benutzersitzungen auszuführen. Wenn ich versuche, sie zu verwalten, stelle ich fest, dass beim Ändern eines Benutzers über sudo -u $user -ioder sogar su - $userdie Umgebung nicht XDG_RUNTIME_DIRfestgelegt wurde, was das systemctl --userArbeiten verhindert. Wenn ich jedoch sshdirekt in diesen Benutzer hineinkomme, ist er richtig eingestellt.

Wenn ich die Dokumentation richtig verstehe, sollte dies libpam-systemdbeim Erstellen der Benutzersitzung festgelegt werden. Das User Slice wird korrekt gestartet, da das Verzeichnis existiert, auf das XDG_RUNTIME_DIRpoint ( /run/users/$uid) verweisen soll . Ich zögere, es einfach fest einzuschreiben, sagen wir .bash_profilemal, weil das kitschig erscheint (obwohl es funktioniert), wenn Pam sich darum kümmern sollte.

Ich kann natürlich, fügen Sie XDG_RUNTIME_DIRzu env_keepin sudoers, aber das würde bewahren nur die Umgebung des sudoing Benutzer, die nicht das, was ich will. Ich mag die Zielumgebung des Benutzers.

Was mich allerdings wirklich wundert, ist, wie kommt es, dass die Sitzung korrekt mit ssh, aber nicht mit suoder eingerichtet ist sudo -i?

Ich habe dieses Problem auf meinem Fedora 25-System repliziert.

Ich habe einen sehr verdächtigen Zustand im Quellcode gefunden. https://github.com/systemd/systemd/blob/f97b34a/src/login/pam_systemd.c#L439 Es sieht so aus, als ob es mit normalem sudoVerstand geschrieben wurde, aber nicht sudo -u non-root-user.

machinectl shell --uid=non-root-user hat wie gewünscht gearbeitet.

systemd-run schien nicht wie gewünscht zu funktionieren, obwohl in der machinectl-Dokumentation darauf verwiesen wurde.

Einige machinectl-Befehle funktionieren nicht, wenn Sie SELinux im Moment aktiviert haben, und diese spezifischen Befehle funktionierten erst bei mir setenforce 0. Allerdings bin ich gerade dabei, Workarounds zu versuchen, um machinectl zum Laufen zu bringen, da ich möchte, dass es SELinux schreibt. Daher ist es möglich, dass mein Geigen dazu führt, dass z machinectl shell. B. eine Zeitüberschreitung auftritt .

EDIT: Ich denke, dieser Code wurde nach dieser Diskussion eingeführt . Und anscheinend su -/ sudo -ikönnte gemacht werden, um zu arbeiten, aber niemand hat es (noch) umgesetzt.

Was ich mich allerdings wirklich wundere, ist, warum die Sitzung mit ssh richtig eingerichtet wurde, aber nicht mit su oder sudo -i?

https://github.com/systemd/systemd/issues/7451#issuecomment-346787237

Tut mir leid, aber "su" ist ein Tool zum vorübergehenden Ändern von Benutzeridentitäten und sehr wenigen anderen Prozessanmeldeinformationen. Es ist kein Tool zum Öffnen einer völlig neuen Anmeldesitzung. Eine neue Anmeldesitzung hat eine sehr gut definierte, makellose Konfiguration, die nichts von einer anderen Sitzung erbt. Dies ist jedoch bei "su" -Uid-Änderungen nicht der Fall: Der Großteil der Ausführungsumgebung wird in zahlreichen und nicht offensichtlichen Fällen vererbt Möglichkeiten, zum Beispiel MAC-Kontexte, Audit-Kontexte, Cgroup-Kontexte, Namespace-Kontexte, Zeitplanung, Timer-Granularität, ...

Wenn Sie eine vollständig neue Sitzung möchten, verwenden Sie etwas wie "machinectl login" oder "machinectl shell", mit dem Sie eine vollständig saubere, unabhängige Umgebung ohne versteckte Prozesseigenschaften erhalten, von der aus Sie sie aufrufen.

logind-Sitzungen sind größtenteils an das Audit-Sitzungskonzept gebunden, und Audit-Sitzungen bleiben von "su" unberührt. Tatsächlich werden sie als "versiegelt" definiert, dh so, dass ein Prozess, der einmal in eine Sitzung eingetreten ist, immer erhalten bleibt mit ihm und seinen Kindern, dh die einzige Möglichkeit, eine neue Sitzung zu erhalten, besteht darin, etwas von PID 1 (oder etwas Ähnlichem) abzutrennen, das nie Teil einer Sitzung war.

Oder anders gesagt: Das, was Sie über "su" aufrufen, wird in "loginctl" gut angezeigt. Es bleibt jedoch Teil Ihrer ursprünglichen Sitzung, Sie haben sich ursprünglich angemeldet. Sie können dies überprüfen, indem Sie "loginctl status" für die ID der ursprünglichen Sitzung aufrufen (die Sie durch echo $ XDG_SESSION_ID sehen können).