libvirt-UUID.files not found"

29. Oktober 2024 · Anwendungen · andreas · Kein Kommentar

Beim Start einer virtuellen Maschine wird normalerweise mit Hilfe von virt-aa-helper - je nach Bedarf - entweder ein neues Apparmor-Profil erzeugt oder ein bestehendes Profil für die zu startende Maschine modifiziert:

When a VM/container is started, libvirtd decides whether to ask virt-aa-helper to create a new profile or modify an existing one. [Quelle]

Beim Stoppen der virtuellen Maschine sollte das Profil dann auch wieder entfernt werden:

When the VM/container is shutdown, libvirtd asks virt-aa-helper to remove the profile, and virt-aa-helper unloads the profile from the kernel [Quelle]

Leider scheint virt-aa-helper beim Aufräumen aber schlampig zu arbeiten, denn während die Datei “libvirt-UUID.files” tatsächlich mit dem Stoppen der virtuellen Maschine aus dem Verzeichnis “/etc/apparmor.d/libvirt/” verschwindet, verbleibt die Datei “libvirt-UUID” dort weiterhin.

Über genau diesen Schiefstand stoplert aa-genprof beim Start, denn in “libvirt-UUID” ist ein Verweis auf die Datei “libvirt-UUID.files” enthalten, die aber nicht mehr existiert:

#include <libvirt/libvirt-UUID.files>

Zur Lösung gibt es zwei Ansätze, die beide in der Vergangenheit zu keinen Komplikationen geführt haben:

Erzeugen der fehlenden Datei

Um den Fehler zu beheben, kann z.B. über das “touch”-Kommando eine leere Datei mit dem gesuchten Namen erzeugt werden:

$ sudo touch "/etc/apparmor.d/libvirt/libvirt-UUID.files"

Somit ist die Include-Bedingung erfüllt und aa-genprof startet ohne Fehlermeldung.

Entfernen der vorhandenen Profilreste

Da beim nächsten Start der virtuellen Maschine bei Bedarf sowieso ein neues Profil angelegt wird, ist es auch gefahrlos möglich, die noch vorhandenen Profildateien zu entfernen:

$ sudo rm "/etc/apparmor.d/libvirt/libvirt-*"

Es sollte allerdings darauf geachtet werden, den Ordner nicht komplett zu leeren oder gar zu löschen, da die darin enthaltenen Template-Dateien (“TEMPLATE.lxc” bzw “TEMPLATE.qemu”) werden von virt-aa-helper als Vorlage zum Erstellen neuer Profile verwendet.

UUID ist Platzhalter für die UUID der jeweiligen virutellen Maschine, also z.B. “libvirt-a47d1fb1-22f7-467d-ad14-36242f971df4”

Robert Beckebans RBDOOM-3-BFG

06. März 2023 · Spiele · andreas · Kein Kommentar

Was mit Quake 2 funktioniert, funktioniert auch mit Doom 3 - zumindest mit der Doom 3 BFG-Edition. Für diese wurde das ursprüngliche Doom 3 nicht nur überarbeitet, sondern auch um die Missionspakete “Resurrection of Evil” und “The Lost Mission” sowie die Vorgängerspiele Doom und Doom 2 ergänzt.

Die am weitesten verbreitete Portierung der Spiele-Engine stammt von Robert Beckebans, der das Projekt “RBDOOM-3-BFG” bis heute kontinuierlich pflegt und auftretende Fehler bereinigt.

RBDOOM-3-BFG is based on DOOM-3-BFG and the goal of this port is to bring DOOM-3-BFG up to latest technology in 2023 making it closer to Doom 2016 while still remaining a DOOM 3 port regarding the gameplay. [Quelle]

Die benötigten Dateien können entweder direkt von der Projektseite auf Github heruntergeladen oder - sofern verfügbar - aus den offiziellen Paketquellen einer Linux-Distribution installiert weden:

$ sudo apt install rbdoom3bfg

Wie üblich sind bei der Spiele-Engine keinerlei Inhalte enthalten, diese müssen zusätzlich bereitgestellt werden. Der einfachste (legale) Weg führt entweder über einen Kauf bei Steam oder GOG.com, die weitere Vorgehensweise ist auf der Projektseite beschrieben.

Sofern die Installationsdatei von GOG.com vorliegt, kann diese auch - statt wie empfohlen umständlich über Wine installiert - direkt mit “innoextract” entpackt und anschließend verwendet werden:

$ innoextract setup_doom_3_bfg_1.14_$13452$.exe

Sobald die Spieldaten entpackt wurden, können diese an einen beliebigen Ort “MEIN-PFAD” kopiert werden:

	$ mkdir -p /MEIN-PFAD/Doom3BFG/
$ cp -r --preserve=timestamp app/base /MEIN-PFAD/Doom3BFG/

Anschließend sollte noch das Konfigurationsverzeichnis erzeugt und eine “autoexec.cfg” darin abgelegt werden, welche die Sprache auf die gewünschte Version setzt - bei den Installationsdateien von GOG.com wird sonst automatisch “Japanisch” als Standardsprache gewählt.

	$ mkdir -p ~/.local/share/rbdoom3bfg/base/
$ echo 'seta sys_lang "english"' >> ~/.local/share/rbdoom3bfg/base/autoexec.cfg

Dann kann Doom 3 BFG gestartet werden, wobei zu beachten ist, daß es keinerlei Parameter gibt, um das Datenverzeichnis anzugeben. Das ausführbare “rbdoom3bfg” ist im Ordner “MEIN-PFAD” zu starten.

Wer möchte, kann sich den Start noch mit Hilfe einer “.desktop”-Datei erleichtern.

	$ cp --preserve=timestamp app/language_setup.png /MEIN-PFAD/Doom3BFG/

$ vi ~/.local/share/applications/Doom3BFG.desktop

[Desktop Entry]
Type=Application
Encoding=UTF-8
Name=Doom 3 BFG
Exec=/usr/games/rbdoom3bfg
Icon=/MEIN-PFAD/Doom3BFG/language_setup.png
Path=/MEIN-PFAD/Doom3BFG/
Terminal=false
Categories=Game

Auch hier ist “MEIN-PFAD” mit dem oben gewählten Pfad zu ersetzen.

Optional: AppArmor Profil

Optional kann auch noch ein AppArmor Profil erzeugt und in “/etc/apparmor.d” abgelegt werden. Folgendes Profil reicht (hier) aus, um RBDOOM-3-BFG mit einer NVidia-Graphikkarte zu spielen:

	# 2023-03-02 athul/initial
#include <tunables/global>

/usr/games/rbdoom3bfg {
  #include <abstractions/X>
  #include <abstractions/base>
  #include <abstractions/audio>
  #include <abstractions/nvidia>

  deny network,
  @{HOME}/.local/share/rbdoom3bfg/** rwk,
  /MEIN-PFAD/Doom3BFG/** r,
  /sys/devices/** r,
  /var/lib/dbus/machine-id r,
  /proc/** r,
  /dev/nvidia* rw,
}

Zu beachten ist die Anpassung von “MEIN-PFAD” sowie das anschließende Neuladen der AppArmor-Profile, nachdem “rbdoom3bfg” hinzugefügt wurde.

Aktualisiertes AppArmor-Profil für Sublime Text 4

09. August 2021 · Anwendungen · andreas · Kein Kommentar

Nach der Aktualisierung auf Version 4 wollte Sublime Text mit dem alten AppArmor-Profil nicht mehr starten. Ein Blick ins Log half, die Problemstellen zu lokalisieren und das Profil anzupassen:

	# 2020-05-11 athul/initial
# 2020-09-29 athul/replaced abstractions/evince
# 2021-07-26 athul/changed permissions for /opt/sublime_text/sublime_text from "mr" to "mrix",
#   added settings for /opt/sublime_text/plugin_host-3.3, /opt/sublime_text/plugin_host-3.8
#   chandged permissions for /opt/sublime_text/** from "r" to "mr", removed /opt/sublime_text/plugin_host
# 2021-08-19 athul/added write permission to /tmp/*

#include <tunables/global>

/opt/sublime_text/sublime_text {
  #include <abstractions/X>
  #include <abstractions/base>
  #include <abstractions/dbus-session-strict>
  #include <abstractions/fonts>

  deny network,

  /opt/sublime_text/ r,
  /opt/sublime_text/** mr,
  /opt/sublime_text/plugin_host-3.3 mrix,
  /opt/sublime_text/plugin_host-3.8 mrix,
  /opt/sublime_text/sublime_text mrix,
  /proc/filesystems r,
  /usr/share/** r,
  /usr/bin/perl mrix,
  /usr/bin/sassc mrix,
  owner /dev/shm/* rwl,
  owner /run/user/** rw,
  owner /tmp/* w,
  @{HOME}/** rwk,
  @{HOME} rw,
}

Es musste die Berechtigung für Sublime Text um “ix” (execute and inherit the current profile) ergänzt, die Einstellungen für den Plugin-Host geändert und die Berechtigungen für die Dateien unterhalb von “/opt/sublime_text/” um “m” (memory map executable) erweitert werden.

Aktualisierungen:
2021-08-19: Fehlende Berechtigung zum Schreiben in “/tmp” ergänzt
2021-08-09: Aktualisierung für Sublime Text 4

Aktualisiertes AppArmor-Profil für Sublime Text

30. September 2020 · Betriebssysteme · andreas · Kein Kommentar

Das AppArmor-Profil für Sublime Text hat sich im Praxiseinsatz bewährt, allerdings sind im Laufe der Zeit ein paar Nebenwirkungen aufgetreten: trotz expliziter Genehmigung des Lese- und Schreibzugriffs auf alle im Besitz des Benutzers befindlichen Dateien unterhalb von “/home”

owner /home/** rw,

war es nicht möglich, z.B. die Datei “.bashrc” zu bearbeiten. Dies wurde auch entsprechend im Log protokolliert:

	apparmor="DENIED" operation="open" profile="/opt/sublime_text/sublime_text" name="/home/buster/.bashrc" pid=5507 comm="file_read_threa" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000

Ursache hierfür war das Einbinden der Datei “abstractions/evince”

#include <abstractions/evince>

welche wiederum den Regelsatz um den Inhalt der Datei “abstractions/private-files” erweiterte

#include <abstractions/private-files>

wodurch letztendlich die Regel

deny @{HOME}/.bash* mrk,

im Profil aktiv war. Diese unterbindet den Lesezugriff auf alle Dateien im “Home”-Verzeichnis des Benutzers welche mit “.bash” beginnen, weshalb die spätere Genehmigung ins Leere läuft.

Das aktualisierte Profil sieht wie folgt aus:

/etc/apparmor.d/opt.sublime_text.sublime_text
# 2020-05-11 athul/initial
# 2020-09-29 athul/replaced abstractions/evince

#include <tunables/global>

/opt/sublime_text/sublime_text {
  #include <abstractions/X>
  #include <abstractions/base>
  #include <abstractions/dbus-session-strict>
  #include <abstractions/fonts>

  deny network,

  /opt/sublime_text/ r,
  /opt/sublime_text/** r,
  /opt/sublime_text/plugin_host mrix,
  /opt/sublime_text/sublime_text mr,
  /proc/filesystems r,
  /usr/share/** r,
  /usr/bin/perl mrix,
  /usr/bin/sassc mrix,
  owner /dev/shm/* rwl,
  owner /run/user/** rw,
  @{HOME}/** rwk,
  @{HOME} rw,
}

Neben dem Ersetzen von “abstractions/evince” wurde das Profil noch um eine Zugriffsregel für den Perl-Interpreter sowie den Sass CSS-Precompiler erweitert und auf die Variable “@{HOME}” aus “tunables/global” statt der statischen Pfadangabe “/home/…” zurückgegriffen.

Als Best Practice sollte man zur Minimierung von Nebenwirkungen mit Hilfe von “aa-genprof” die Zugriffsrechte lieber dediziert vergeben statt die vorgeschlagenen Includes einzubinden.

Internet-Zugriff für Sublime Text unter Debian unterbinden

15. Mai 2020 · Betriebssysteme · andreas · Kein Kommentar

Als Texteditor ist hier Sublime Text in der lizenzierten Version im Einsatz.

Es ist aus meiner Sicht vollkommen legitim, daß ein Lizenzinhaber gelegentlich überprüft, ob die zugewiesene Lizenz noch gültig ist. Sublime Text führt diese Online-Überprüfung aber nach jedem Start durch, was im Hinblick auf die Privatsphäre suboptimal ist - letzendlich geht es im Rahmen der erworbenen Lizenz die Entwickler nichts an, ob der Editor fünfzig mal am Tag oder um drei Uhr nachts gestartet wird.

Eine Diskussion mit dem Thema “Sublime Text calling home to license.sublimehq.com on every start?” im offiziellen Sublime Text-Forum hat leider zu keinem greifbaren Ergebnis geführt. Da auch die Sales FAQ nicht verlangt, daß das Programm nach Hause telefonieren darf / kann / soll / muss, ist eine anwendungsbezogene Sperrung des Netzwerk-Zugriffs eine naheliegende Option.