LWN.net – GNOME, Wayland und Umgebungsvariablen
Obwohl Strode zu einer „modernen“ Lösung für Umgebungsvariablen übergehen möchte, spürt er offensichtlich den Druck, der durch die breitere Offenlegung eines defekten Systems entsteht. So lautet sein jüngster Kommentar zu dem Fehler zum Zeitpunkt des Schreibens: „Ja, ich überlege, hier nachzugeben.“ Für Fedora 25 wird es also wahrscheinlich ein Update geben, das die Login-Shell für den Anmeldevorgang wiederherstellt; eine „richtige Lösung“ muss bis später warten.
Es ist jetzt Fedora 28... wo stehen wir bei der "richtigen Lösung"? Gibt es schon eine zukunftsweisende Möglichkeit für Benutzer, Umgebungsvariablen für ihre Sitzungen festzulegen?
Also ein Ersatz, ~/.bash_profileder unter Fedora und hoffentlich auch anderswo funktioniert.
Antwort1
Für GNOME 3.24, StrodeGnome-Sitzung zurückgesetztum Umgebungsvariablen durch Ausführen einer Login-Shell zu laden.
Im selben Kommentar haben sie einen Patch für Gnome-Session beigefügt, um diese Sitzungsumgebungsvariablen an systemd-Benutzerdienste zu übertragen. Dazu gehören gnome-terminal, also ist es ziemlich wichtig :).
Der GDM-Sitzungsstarter war bereitsgepatchtin 3.22, um die Umgebung aus zu importieren systemd --user. Daher wird die systemd-Umgebung in die Sitzung importiert, dann von der Login-Shell geändert und das Ergebnis wird auch nach zurückkopiert systemd --user.
Das sollte eigentlich funktionieren ... außer beim Testen auf Fedora 28, da funktioniert es z. B. für PATH nicht richtig, weil der GDM-Sitzungsstarter nicht zulässt, dass Systemd-Umgebungsvariablen die bereits vorhandene Umgebung überschreiben.Ich habe es im GNOME Issue Tracker gemeldet.
Es warvereinbartdass login(für die Textkonsole)könnteakzeptieren einige Patches zum Laden der Umgebungskonfiguration vor dem Starten der Benutzer-Shell, aber es gibt bisher keine Änderung inutil-linux v2.32.
Ich habe mir nicht einmal die Mühe gemacht, nach SSH-Patches zu suchen :).
Die systemd-Umgebung war bereits in konfigurierbar user.conf. Als Teil dieser Bemühungen wurde systemd v233gewonnenein environment.d/Format, das jetzt beispielsweise das Voranstellen eines zusätzlichen Verzeichnisses an die bestehenden Listen PATHoder LD_LIBRARY_PATHSuchlisten unterstützt.
Ich dachte, der beste Ort zum Festlegen von Umgebungsvariablen für Benutzeranmeldungen wäre ein PAM-Modul – das haben wir sogar pam_envschon getan. Die Logik ist
Dazu Login, GDM, SSHD (das wird nie passieren) usw. anzufordern, ist wirklich eine schlechte Lösung.
Leider pam_envist die Konfiguration von zwischen den Distributionen ärgerlich inkonsistent... und es scheint, dass es dafür einen guten Grund geben könnte. Die ~/.pam_environmentFunktiongilt als großes "Fußgewehr" für die Sicherheit. Siehe auchCVE-2010-4708.
Sehen Sie sich
pam_execzum Beispiel Folgendes an. Man könnte sich vorstellen, dass ein Systemadministrator es verwendet, um eine Konfiguration nach der Anmeldung oder so etwas vorzunehmen, aber ein Benutzer könnte Root werden, indem er LD_PRELOAD einstellt. Oder pam_selinux verwendet tatsächlich pam_getenv direkt, sodass ein Benutzer damit herumspielen könnte. Aber mir geht es nicht wirklich um diese spezifischen Beispiele, sondern nur darum, zu veranschaulichen, dass es Risiken birgt, es als Root auszuführen, und wir können diese Risiken vollständig umgehen und eine ganze Klasse potenzieller Sicherheitsfehler eliminieren, indem wir es nur etwas später im Anmeldevorgang tun. Als allgemeine Regel gilt: Wenn Sie Code nicht als Root ausführen müssen, sollte er nicht als Root ausgeführt werden! Natürlich bin ich immer noch hin- und hergerissen, weil es logistisch umständlicher ist, es später zu tun, aber es besteht für mich kein Zweifel, dass es riskanter ist, es als Root auszuführen, als als Benutzer.Im pam_exec-Handbuch heißt es ausdrücklich: „Bei von pam_exec aufgerufenen Befehlen muss berücksichtigt werden, dass der Benutzer Kontrolle über die Umgebung haben kann.“
Bezüglich pam_env: Beachten Sie, dass Fedora es oben auf den PAM-Stapel setzt und ~/.pam_environment standardmäßig deaktiviert.
Es ganz oben auf dem Stapel zu platzieren ist ein Fehler und verstößt gegen die ausdrückliche Warnung, dies nicht zu tun: „Da das Setzen von PAM-Umgebungsvariablen Nebenwirkungen auf andere Module haben kann, sollte dieses Modul das letzte auf dem Stapel sein.“
[...] Angesichts der hier herrschenden Verwirrung handelt es sich offensichtlich um eine Fußflinte
Die Grundidee, hierfür die Shell-Konfiguration zu verwenden, scheint auch bei der grafischen Anmeldung unter Ubuntu Desktop 16.04 zu funktionieren. Es gibt jedoch einen Unterschied. Fedora erstellt ~/.bash_profilestandardmäßig, was (für Bash) dazu führt, ~/.profiledass es ignoriert wird. Ubuntu und andere Debian-basierte Distributionen erstellen ~/.profilestattdessen standardmäßig. (D. h. diese Dateien werden bereitgestellt, wenn Sie einen neuen Benutzer erstellen, von /etc/skel).
(Ich habe dies kürzlich unter Ubuntu verwendet. Ubuntu scheint sich im Laufe der Zeit hinsichtlich der Ausführung einer Login-Shell für GUI-Sitzungen geändert zu haben. Siehe z. B.https://superuser.com/questions/183870/difference-between-bashrc-and-bash-profile/183980#183980,https://askubuntu.com/questions/40287/etc-profile-not-being-sourced,„Warum ist Gnome-Terminal keine Login-Shell?“, Und„Was bedeutet Shell-Login (‚bash -l‘)“).