Login
Newsletter
Werbung

Thema: Xfce 4.16 ohne GTK4 und Wayland

3 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
1
Von klopskind am Fr, 23. August 2019 um 23:20 #

Zu Ihrem letzten Absatz eine kleine Anekdote:
Obwohl ich als Laie die Technik dahinter nicht ganz raffe, hat GNOME bzw. einige Komponenten seit der Nutzung gewisser Middleware-Features (von DBus oder systemd) eine gewisse Eigenheit: So werden gewisse Anwendungen per DBus-Activation via systemd --user angestoßen, so z.B. das GNOME-Terminal. Das Problem ist, das die traditionellen Regeln der Vererbung der umask(2) der Sitzung nicht mehr greift, da dieses Konzept anders funktioniert als die bisherigen Sitzungsverwaltungen.

Es ist schon ein wenig her, sodass ich vermutlich einige Details vergessen habe. Mein Ziel war es, die die standardmäßig Einstellung für umask(2) zu ändern, sodass normale Nutzersitzungen (tty und GNOME) standardmäßig eine umask 0002 statt der üblichen 0022 nutzt.
Das kann deshalb sinnvoll sein, um die Zugriffsrechte unter den Einzelnutzern eines Systems standardmäßig strikter einzuschränken - und das ohne den Nutzern die Eigene Kontrolle über diese Einstellung zu verwehren.

Dafür gibt es inzwischen unterschiedlichste Konfigurationspunkte, die alle unterschiedlich nuancierte Konsequenzen haben: /etc/profile, /etc/login.defs oder via PAM (distributionsspezifisch) mittels pam_umask(8), z.B. /etc/pam.d/common-session (Debian und Derivate). Letzteres war meiner Meinung nach die beste Methode für eine Systemweite Standardeinstellungsänderung, falls die Distribution PAM unterstützt (bspw. unterstützt Slackware PAM aus mir teils nachvollziehbaren Gründen bis heute nicht).
Soweit so gut. Ändert man die PAM-Regeln entsprechend und startet eine neue GNOME-Sitzung samt GNOME-Terminal, so gibt ein umask(1p) weiterhin 0022 aus, obwohl mit dem traditionellen Verhalten 0002 zu erwarten wäre.

Die Überschreibung des UMask-Attributs einer entsprechenden Unit-Datei von systemd, z.B. dies des Login-Managers, Session-Managers oder DBus (Welche wäre korrekt?), hatte ich damals dann nicht mehr probiert und aufgegeben, da ich systemd noch nicht hinreichend durchdrungen hatte. Erst später las ich dann davon, dass sich das Problem so lösen lassen müsste.

Fakt ist, dass das neue Verhalten zwar dokumentiert ist, aber nur an der neuen Konfigurationsschnittstelle von systemd (Unit-Dateien). Die alten Konfigurationsschnittstellen wurden durch diese Eigenheit von GNOME de facto falsch oder unvollständig und damit unbrauchbar oder mindestens irreführend.

Ich finde, dass soetwas gewaltig nervt, gerade wenn man sich ernsthaft bemüht. Und nein, ich finde diesen Anwendungsfall, bzw. die Unterstützung dieser Konfiguration nicht besonders speziell, zumal sie zuvor jahrelang einwandfrei funktionierte, und bis heute keine vernünftigen Hinweise oder Dokumentation existiert bzw. angepasst wurde.

In diesem Sinne kann ich einige Menschen in Ihrer Einstellung zu GNOME >=3.x schon verstehen.

Hattet Ihr ähnliche Erfahrungen?

Disclaimer: Das soll keine Hasstirade gegen GNOME, systemd oder DBus sein. Diese Projekte sind in tolles Geschenk und enorm nützlich. Leider gehen solche Dinge dann häufiger unter.

Quellen: Fast alle hilfreichen Kommentare und Querverweise finden sich in den Antworten dieser Frage, insbesondere aber jener. Unter den Querverweisen befinden sich auch welche auf Fehlerberichte, die leider bis heute vor sich hinschimmeln...

  • 1
    Von Tamaskan am So, 25. August 2019 um 13:49 #

    Das ist natürlich sehr nervig, da gebe ich dir Recht. Mich stört es allgemein unter Linux, dass die Konfigurationsoptionen so verstreut und uneinheitlich sind. Es gab immer wieder Ansätze, das in den Griff zu bekommen, wie YaST von Suse, oder die deklarative Konfiguration von NixOS, oder eben auch systemd mit seinen Unit-Files, aber leider führt das dann oft dazu dass man parallel alles konfigurieren muss.

    Besonders schlimm ist ja Netzwerkkonfiguration. Auf dem Desktop hat sich ja zum Glück der NetworkManager durchgesetzt, aber auf dem Server gibt es je nach Distribution eine eigene Methode, /etc/network/interfaces bei Debian, netplan bei Ubuntu, wicked bei Suse, netctl bei Arch, und es gibt natürlich noch systemd-networkd, und wenn man ganz viel Pech hat, überschreibt irgendein Tool die Konfiguration eines anderen Tools. Yeah!

Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung