Alternativer Titel: "Problem gelöst...Jetzt erst recht!". Gestern erreichte mich ein Kommentar, was mich dazu brachte erneut über diesen merkwürdigen Bug "Not authorized" nachzudenken. Egal wie ich es anstellte, sobald ich versuchte etwas in Thunar als normaler Nutzer zu mounten, wurde ich mit einer Meldung von PolicyKit abgewimmelt.
Das Problem hat zwei Dimensionen. Zum einen scheint der Bug mit der Wahl des Loginmanagers zusammen zuhängen. Slim erkennt oder wählt hier zumindest nicht die richtigen Einstellungen, damit PolicyKit die Rechte für die einzelnen Nutzer des Systems setzen kann. Auch mit einer Lösung ohne Loginmanager hatte ich keinen Erfolg. Man könnte z.B. mit der xinitrc-Methode ebenfalls in eine grafische Desktopumgebung starten:
exec ck-launch-session dbus-launch openbox-session
Ich schaute mir noch einmal den entsprechenden Debian-Fehlerbericht an. Der letzte Eintrag verweist dabei auf den Loginmanager lightdm. Lightdm scheint ziemlich neu zu sein, denn es gibt keine Version für Squeeze. Er selbst nennt sich kompatibel mit aktuellen Entwicklungen von PolicyKit und PAM. Vielleicht hatte ich hier mehr Glück.
Tatsächlich lassen sich nach einer Installation von Lightdm wieder externe Speichermedien ohne Probleme auch in Thunar mounten. Nur die restriktive Einstellung, dass lediglich Administratoren interne Partitionen oder Medien mounten konnten, gefiel mir noch nicht richtig.
Damit auch interne Laufwerke oder Partitionen ohne die Rechte eines Admins eingehängt werden können, genügt ein kleiner Eintrag in /etc/polkit-1/localauthority/50-local.d/10-udisks.pkla.
Die Textdatei kann beliebig benannt werden. Wichtig ist nur, dass der Dateiname auf .pkla endet. Mehr Informationen dazu gibt es auch mit man pklocalauthority. Interessanterweise schlägt ubuntu.com vor, dass man den Nutzer zur Admingruppe hinzufügen sollte, wenn man interne Datenträger mounten möchte. Ich sehe dabei das Problem, dass dadurch auch andere Aktionen möglich werden, die besser nur durch root ausgeführt werden und nicht durch irgendeinen Benutzer auf dem System.
Am Ende erstellte ich die Datei 10-udisks.pkla mit folgendem Inhalt
[Storage Permissions] Identity=unix-group:disk Action=org.freedesktop.udisks.filesystem-mount;org.freedesktop.udisks.filesystem-mount-system-internal;org.freedesktop.udisks.filesystem-unmount-others;org.freedesktop.udisks.drive-eject;org.freedesktop.udisks.drive-detach;org.freedesktop.udisks.luks-unlock;org.freedesktop.udisks.inhibit-polling;org.freedesktop.udisks.drive-set-spindown ResultAny=no ResultActive=yes ResultInactive=no
Fügt man den normalen Benutzer zur Gruppe "disk" hinzu, kann dieser ab sofort wieder Partitionen oder Speichermedien auch intern mounten. PolicyKit ist sicher eine fortgeschrittene Möglichkeit Benutzerrechte zu definieren und diese auf verschiedene Anwendungen anzuwenden. Leider ist die Dokumentation zu sehr auf Entwickler ausgelegt. Als Endanwender erschließen sich manche Entscheidungen von Debian und PolicyKit nicht auf den ersten Blick. Danke auch für die Hinweise an diesen Post im Forum von Arch Linux.
Wem Debians restriktive Politik beim Mounten von Datenträgern bisher missfallen hat, kann mit einer kleinen Änderung dieses Verhalten schnell ändern. Man muss vorher nur wissen, dass es mit PolicyKit zu tun hat. 😉
Problem gelöst…
NICHTjetzt aber!Vielen Dank für deine Hilfe, apo! Ich habe mittlerweile insgesamt ca. 9 Stunden damit verbracht das Problem zu lösen. Dabei habe ich natürlich wieder viel dazugelernt und neues entdeckt.
Als ich fast dabei war alles in die Ecke zu werfen fand ich einen Blogeintrag bei tech-shack.de. Das Problem ist so blöd wie einfach. Debian legt bei der Installation in die fstab einen Eintrag mit /dev/sdb wenn ein CD-Laufwerk vorhanden ist. Wenn dann auf sdb ein USB-Gerät kommt funktioniert das natürlich nicht. Wenn die Zeile auskommentiert wird läuft es. Debian legt für das CD-Laufwerk noch einen weiteren Eintrag an, dieser sollte stehen bleiben. Allerdings kann es sinnvoll sein in der korrekten Zeile des CD-Laufwerks den zugewiesenen Wert “user” in “users” zu verändern. Siehe dazu fstab.
Danach gab es auch keine Probleme mehr mit den USB-Sticks. Alle konnten ohne Probleme gemountet werden, solange kein Display-Manager verwendet wurde.
Slim konnte dann immernoch nicht mounten.
Deswegen habe ich Lightdm installiert. Das funktionierte dann problemlos, wie du schon geschrieben hast. Da Lightdm aber kein auto-login kann (siehe) habe ich mich für gdm3 entschieden. Dort lässt sich alles mounten und einen auto-login gibt es auch.
Ein Tipp am Rande den man sich bei dieser Gelegenheit mal anschauen kann: gnome-disk-utility
Leider schief gegangen mit der Formatierung im Kommentar:
Allerdings kann es sinnvoll sein in der korrekten Zeile des CD-Laufwerks den zugewiesenen Wert “user” in “users” zu verändern. Siehe dazu fstab.
Ich habe die Formatierung im ersten Kommentar angepasst.
Danke für die ausführliche Beschreibung deiner Lösung. Bei mir hat es zum Glück keine 9 Stunden gedauert, aber durch deinen Anstoß kenne ich nun auch lightdm und policykit etwas besser. Mit der PolicyKit Lösung bin ich derzeit zufrieden und denke auch, dass dieses Problem nun abgehakt ist. 😉
Kann sein dass lightdm z.B. keine console-kit session anlegt ?
Würde zumindest manche Probleme erklären können.
Nein, im Gegenteil. Lightdm hat für mich ein Problem mit console-kit gelöst. Scheinbar hat aber Slim dieses Problem. Mit der Kombination aus lightdm und der manuellen Konfiguration der policykit Rechte, läuft aber nun alles wieder.
Ich muss echt sagen, das mich das Thema PolicyKit und Mountrechte schon seit geraumer Zeit an nervt. Ich frage mich warum die das nicht schaffen, mal nutzbare Defaults zu bringen da mit es einfach funktioniert. Ich habe keine Lust mich Stundenlang damit zu beschäftigen wie PolicyKit funktioniert – es soll einfach laufen wie im Ubuntu ohne dass ich Ubuntu nutze 😉
Ich vermute seit Debian Squeeze eingefroren wurde, gab es einige entscheidende Veränderungen bei PolicyKit und Co. Leider haben noch nicht alle Loginmanager sich daran angepasst. LightDM, was auch Ubuntu nun standardmäßig einsetzt, scheint mir die vernünftigste Lösung zu sein. Endlich ein Standard, der sich an alle Desktopumgebungen leicht anpassen lässt und die Rechte beim Login richtig setzen kann.
Auf der anderen Seite ist Debian sicherheitsbewusster und konservativer bei der Rechtevergabe. Ich mag Debian auch ehrlich gesagt dafür. Als normaler Desktopbenutzer ist das aber oft schwer nachzuvollziehen, da ist Ubuntu einfach einsteigerfreundlicher, weshalb ich genau weiß, was du mit deinem Kommentar meintest. 🙂
Aber was hat PolicyKit mit dem Loginmanager zutun. Ich Log mich über die Console ein und mache „startx“.
Sicherheitsbewusster ist ja gut. Es wäre aber gut wenn man ein Paket welches vereinfachte Desktopbenutzung installiert sodass einem keine Steine in den Weg gelegt werden beim tägl. Gebrauch. Nun gut – wird sich wohl nicht ändern.
Der Loginmanager startet Policykit im Regelfall. Mit dem ganzen Policykit Ansatz sollte das Authorisieren von unpriviligierten Prozessen einer feinkörnigeren Kontrolle unterworfen werden, so dass man z.B. nicht mehr auf sudo zurückgreifen muss, was einem Prozess komplette Root Rechte verschafft. So viel zur Theorie. 🙂
Im Arch Linux Forum gibt es zu startx und PolicyKit auch einen interessanten Eintrag. Leider hat mir der Tipp dort nicht geholfen.
https://wiki.archlinux.org/index.php/Startx
Hi,
auf den von mir überwachten Rechnern (es sind 5) läuft überall arch und slim. Alle Fenstermanager werden durch die .xinitrc gestartet. Dabei ist mir aufgefallen, dass vor einiger Zeit slim selbst „ck-lauch-session“ aufruft. In den .xinitrc-Dateien war es auch drinn. So wurden dann zwei Sessions gestartet und auch hier funktionierte der Mount nicht mehr. ck-list-sessions zeigt die Sitzungen an. Dann habe ich in der /etc/slim.conf editiert und die .xinitrcs so angepasst, dass es läuft. Vielleicht ist die Verschachtelung ja auch Euer problem. Ich meines, dass das auch im en Archwiki steht.
Grüße
In meiner Debian Installation heisst die Benutzer-Gruppe nicht „disk“ sondern „plugdev“.