Hallo kB,
ganz grundsätzlich würde ich es für geschickter halten, dass Dienstprogramm udisksctl in einen eigenen Unterartikel auszulagern. Bei udisksctl würde ich auf alle Fälle auch udisksctl monitor erwähnen. Denn das ist hilfreich, um Probleme eingrenzen zu können. In der Regel wird man nämlich mehr oder minder Problem haben, wenn man als Administrator auf udisks zurückgreifen muss.
In der Einleitung könnte IMO noch deutlicher gemacht werden, dass
udisks in erster Linie ein Service samt API ist, der vornehmlich für Desktop-Umgebungsentwickler und darauf basierender Programme und eigentlich weniger für Endanwender gedacht ist und dass dieser udisks in der Regel erst bei Problemen wahrnimmt.
udisks vor allem für das Einbinden von "Wechselmedien" durch "normale" (unprivilegierte) Benutzer gedacht ist, denen die für das Einbinden normalerweise notwendigen Root-Rechte fehlen.
wenn immer möglich, die Konfiguration mittels genutzter Client-Anwendung vorgezogen werden sollte.
So habe ich das zumindest aus den verschiedenen man-Pages zu udisks herausgelesen.
Abschnitt Baustelle/UDisks2 (Abschnitt „Benutzung“):
Ich finde den Begriff "Benutzung" nicht so ganz passend. Ich würde es vielleicht eher als "In Erscheinung treten" bezeichnen wollen und dann passiert das aber auch nur, sofern der Vorgang Autorisierung erfordert. Der Endanwender benutzt ja udisks nicht direkt, sondern er benutzt die Client-Programme und die greifen dann per API oder libudisks2 auf udisksd zu bzw. verwenden es. Die Verwendung von udisks im Hintergrund bekommt der Anwender gar nicht mit und nicht bei allen Aktionen die letztlich durch udisks erledigt werden, ist eine Autorisierung erforderlich.
"Funktionsweise" könnte vielleicht auch noch besser passen als "Benutzung".
Die Einbindung eines Dateisystems erfordert immer Systemprivilegien. Bei der Benutzung von UDisks über ein grafisches Programm erfolgt deshalb eine Autorisierung per PolicyKit:
...
Da kommt IMO nicht deutlich genug heraus, dass die Gruppe der Dateisysteme mit HintSystem=0 für keine Benutzergruppe eine Autorisierung erfordern.
Mein Vorschlag wäre:
Die Einbindung eines Dateisystems erfordert immer Systemprivilegien. udisksd läuft daher mit Root-Rechten, so dass es eine durch normale Benutzer ohne diese Rechte veranlasste Einhänge-Operation erfolgreich ausführen kann. Damit normale Anwender nicht jedwede Partition mutwillig ein- oder aushängen können, unterscheidet udisks zwischen System- und Nicht-System-Partitionen (siehe auch #HintSystem):
Abschnitt Baustelle/UDisks2 (Abschnitt „Konfiguration“):
Ich finde die Tabelle gelungen, würde aber die letzte Spalte "Aufgabe" weglassen. Und die Reduzierung auf drei Aufgaben finde ich nicht nötig. Es fehlt da ja auch schon das Konfigurieren hinischtlich HintSystem, das ja nicht nur rein kosmetische Gründe hat.
Man könnte überlegen, ob hier nicht eine Warnung sinnvoll ist, dass die Mount-Optionen nur mit Bedacht geändert werden sollten und das man dabei die Standard-Einstellungen kopieren und dann die Änderung hinzufügen oder Entfernen sollte. Ich finde gerade die Stelle nicht, aber irgendwo hatte ich meine ich gelesen, dass die Voreinstellungen von udisks von den Entwicklern mit Bedacht gewählt wurden auch hinsichtlich darauf, dass udisksd mit Root-Rechten läuft. Ich finde es gerade aber nicht mehr.
Abschnitt Baustelle/UDisks2 (Abschnitt „Fehler-durch-Mount-Option-user“)
Wenn man in der Datei fstab eine Zeile mit einer dieser Optionen für die Verwendung mit UDisks definiert, muss man auch diese Option zu allow hinzufügen, anderenfalls kann der Aufruf bei manchen Treibern fehlschlagen; dies ist jedenfalls bei ntfs-3g der Fall.
Ich hatte auch erst angenommen, dass es daran liegen könnte, aber ich habe versucht die Optionen user und users an verschiedenen Stellen in der /etc/udisks2/mount_options.conf hinzuzufügen und das hat bei ntfs-3g keine Auswirkung gehabt, d.h. ab Ubuntu 22.04 verursacht das Vorhandensein eine dieser Optionen eine Fehlermeldung von udisksd. Das gilt wohlgemerkt für die Situation, dass die Bedingungen aus dem ntfs-3g-Wiki nicht alle erfüllt sind.
Ein grundsätzliches Problem von udisks seit Version 2.9.X ist das aber nicht, weil das so nur im Zusammenspiel mit ntfs-3g auftritt.
Es gab von Ubuntu 20.04 nach Ubuntu 22.04 einen Wechsel von Fuse 2.X auf Fuse 3. ntfs-3g ist aber in allen derzeit aktuellen Ubuntu-Versionen mit fuse-lite 28 (was wahrscheinlich für 2.8 stehen soll) kompiliert. Ich könnte mir auch vorstellen, dass da die Ursache für das neu auftretende Fehlerbild liegen könnte.
Was mir noch fehlt:
udisks kommt mit vordefinierten PolKit-Actions, auflistbar unter anderem mittels pkaction | grep udisks. Die lassen sich bei Bedarf für eigene Polkit-Regeln verwenden. Damit lässt sich ab Ubuntu 23.10 die Autorisierung noch feiner steuern, als alleine mit HintSystem, weil PolKit-Regeln auf JavaScript-Basis verwendet werden können. Vor Ubuntu 23.10, ist das keine Option, weil da das Polkit-Regelwerk nicht fein genug konfiguriert werden kann.
LG,
Newubunti
