Dynamisches Laden von Kernelmodulen beim Zugriff durch Nutzer

Date Tags Linux

Ich stolperte letztens über ein paar alte Image-Dateien welche damals wohl mit CloneCD angefertigt worden waren. Damit liesen sie sich nicht so einfach über die üblichen Linux-Boardmittel einbinden. Und extra ein Windows zu booten um Virtual CloneDrive zu nutzen wäre ja auch irgendwie unsportlich. Zum Glück gibt es die hervorragende Software CDEmu, welche diese Abbilder im CUE/BIN-Format als virtuelles Laufwerk einbinden kann.

Damit der, für CDEmu nötige, Kerneltreiber nur bei Bedarf geladen wird, das aber transparent und ohne Root-Rechte funktioniert, müssen einige Mechanismen ineinandergreifen welche zwar alle Dokumentiert, aber erstaunlich schwer durch Suchen zu finden sind wenn man die entscheidenden Begriffe noch nicht kennt.

  • Um die Gerätedateien für die nachzuladenden Module beim Start des Systems anzulegen gibt es modules.devname. Kernelmodule können also angeben, dass sie eine Gerätedatei brauchen und diese wird beim Start angelegt.
  • Auf Systemen mit Systemd kennt udev das spezielle Tag uaccess. Wird dieses auf einer Gerätedatei gesetzt, so wird dynamisch die ACL an dieser Datei so gesetzt, dass aktuell angemeldete Nutzer auf diese Zugreifen können.
  • Die Regeln von udev werden eigentlich durch das Laden der Kernelmodule, bzw. das Auftauchen von Gerätedateien ausgelöst. Die per modules.devname angelegten Dateien lösen diese Regeln aber nicht aus. udev kennt aber die Option static_node welche udev anweist die Regel auch auf die Platzhalterdatei anzuwenden.

Erst in der Kombination der drei Mechanismen ist es ohne Root, nur mit Login, möglich ein Modul wie den Treiber für das virtuelle Laufwerk dynamisch nachzuladen. Ein weiteres Beispiel für eine udev-Regel welche diese Mechanismen nutzt findet sich übrigens bei der vom Steam-Controller genutzten Datei /dev/uinput:

KERNEL=="uinput", SUBSYSTEM=="misc", TAG+="uaccess", OPTIONS+="static_node=uinput"

CDEmu wirft, wenn die Berechtigungen nicht korrekt gesetzt sind übrigens folgende Fehlermeldung:

FEHLER: Fehler beim Verbunden zum CDEmu Daemon: g-io-error-quark: Error calling StartServiceByName for net.sf.cdemu.CDEmuDaemon: Timeout was reached (24)

Ein Blick in das Log des Daemons mit dem sich cdemu zu verbinden sucht zeigte dann, dass der Service nicht die Berechtigung hat auf den virtuellen Gerätetreiber zuzugreifen:

cdemu0: Kernel I/O: failed to open control device /dev/vhba_ctl: Keine Berechtigung!