Es tut sich etwas in der Welt des Linux-Desktops: Hinter den Kulissen werkeln die Entwickler derzeit an einer Reihe von Neuerungen, die den Desktop modernisieren sollen. Dabei schreckt man auch nicht davor zurück, mit gewohnten Konzepten zu brechen. Vorreiter dieses Trends sind Endless OS und Fedora Silverblue: Bei letzterem handelt es sich um eine – derzeit – experimentelle Variante der Community-Distribution von Red Hat. Und zwar eine, die komplett anders aufgebaut ist als die klassische Desktop-Distribution.

Neue Basis

Der wichtigste Unterschied: Es gibt kein klassisches Paketsystem wie RPM oder DEB, wie es von aktuellen Distributionen gewohnt ist. Stattdessen kommt für den Kern ein System namens OSTree zum Einsatz. Die Entwickler bezeichnen dies selbst als "Git für Betriebssysteme" – und das hat durchaus eine gewisse Berechtigung. Ähnlich wie bei dem Codeverwaltungstool können mit OSTree sämtliche Änderungen problemlos rückgängig gemacht werden. Im konkreten Fall von Fedora Silverblue funktioniert das etwa so, dass neben dem aktuellen System auch immer die Version vor dem letzten Update bereitsteht. Eine Rückkehr auf den alten Systemzustand ist hier also nur einen Tastendruck im Bootloader entfernt.

Dies hat aber noch einen weiteren Vorteil: Da hier mehrere Versionen der einzelnen Dateien vorrätig gehalten werden, kann ein solches Systemupdate problemlos im laufenden Betrieb vorgenommen werden. Bei klassischen Paketsystemen kann es hingegen in solchen Fällen zu Problemen kommen, da die alte Datei einfach überschrieben wird, und dann etwa Bibliotheken in einer anderen Version im Speicher als auf dem Datenträger sind. Bei OSTree kommt die neue Version hingegen erst nach einem Reboot zum Einsatz. Dies ermöglicht es auch gefahrlos sämtliche neue Version im Hintergrund automatisch aktualisieren zu lassen. So ein System hat aber natürlich auch Nachteile, immerhin benötigt das Speichern mehrerer Softwareversionen mehr Platz. Diesen Effekt minimiert man, indem die Daten "dedupliziert" abgelagert werden, also bei weiteren Versionen nur die Änderungen zum Vorgänger gespeichert werden

Bei Fedora Silverblue sind immer zwei Versionen des Betriebssystems verfügbar: Die aktuelle und jene vor dem letzten Update.
Screenshot: Andreas Proschofsky / DER STANDARD

Read only

Mit diesem Ansatz gehen strikte Regeln für die Aufteilung des Linux-Dateisystems einher. So lautet die Grundregel bei Fedora Silverblue, dass die Nutzer lediglich Änderungen am /var-Verzeichnis vornehmen dürfen – alles andere ist hingegen auf "read only" gestellt. Dies soll die Übersicht über das eigene System verbessern, ist doch damit klar, dass man alle Nutzeränderungen in einem Verzeichnis versammelt hat. Erfahrene Linux-User werden sich jetzt natürlich fragen, wie das gehen soll, immerhin gibt es bisher deutlich mehr Verzeichnisse, die von den Usern verändert werden können – allen voran die Nutzerdaten unter /home. Dafür behilft man sich mit Symlinks, /home verweist also schlicht auf /var/home, /usr/local zeigt auf /var/usr/local und so weiter.

Flatpaks

Doch die konzeptionellen Umbauten gehen noch weiter: Werden doch über OSTree nur die wichtigsten Kernkomponenten des Systems geliefert und aktuell gehalten. User-Programme sollen hingegen künftig ausschließlich als Flatpak installiert werden. Dabei handelt es sich um einen noch recht jungen Paketstandard, der erst vor einigen Monaten in der Version 1.0 veröffentlicht wurde. Die Idee dahinter ist – wie auch bei ähnlichen Systemen wie Ubuntus Snap oder AppImage – distributionsübergreifende Pakete anbieten zu können. Dies soll Softwareentwicklern die Arbeit erleichtern, indem sie ein Linux-Paket selbst anbieten können, das dann überall funktionieren soll.

Gerade die Entwickler von kommerziellen Programmen hatten immer wieder darüber geklagt, dass es praktisch unmöglich sei, Linux in seiner Distributiontsvielfalt zu unterstützen. Und auch in der Open-Source-Welt sind längst nicht alle mit dem bisherigen Konzept, bei dem die Distributionen die Pakete erstellen, zufrieden sind. Ist es doch bei Fehlerberichten nicht immer ganz einfach herauszufinden, ob ein Bug durch das Programm selbst oder einen von der jeweiligen Distribution ausgelieferten Patch ausgelöst wurde. Flatpak verwendet hingegen gemeinsame "Runtimes" als Basis für alle Komponenten. Es gibt also etwa eine Runtime für eine einzelne Version von KDE oder GNOME, die von deren Entwicklern selbst geliefert wird, zentrale Bibliotheken für den Desktop werden in der Freedesktop-Runtime zusammengefasst.

Flathub ist der zentrale Anlaufpunkt für Flatpaks.
Screenshot: Andreas Proschofsky / DER STANDARD

Die Sandbox schützt

Aus einer Sicherheitsperspektive ist aber eine andere Eigenheit von Flatpaks viel wichtiger: Sollen hier doch sämtliche Programme in einer eigenen Sandbox laufen – ganz wie man es von mobilen Betriebssystemen wie Android oder iOS gewohnt ist. Das heißt, dass einzelne Programme nur mehr einen eingeschränkten Zugriff auf lokale Daten und Ressourcen haben, und zwar einen der von den Nutzern bestimmt werden kann. Also gibt es auch ein Berechtigungssystem, das den Zugriff auf sensible Informationen wie Standort, Kamera oder Mikrofon einheitlich regelt.

Der Zugriff auf das lokale Dateisystem soll ebenfalls auf diese Weise beschränkt werden. Von Haus aus hat ein Flatpak nur die Erlaubnis Dateien in einem individuell zugewiesenen Unterverzeichnis zu verändern (wer es genau wissen will: zu finden ist diese unter .var/app/$programmid im eigenen Home). Gerade dies stellt einen deutlichen Fortschritt zum Status Quo dar. Bisher hat jedes installierte Programm am Linux-Desktop praktisch uneingeschränkten Zugriff auf alle lokalen Daten der Nutzer – was bei einem Angriff schnell zu einem echten Problem werden kann. Klar ist allerdings auch, dass es noch einige Zeit dauern könnte, bis dieser Vorteil wirklich schlagend wird. Immerhin gehen derzeit alle Linux-Desktop-Programme davon aus, dass sie kompletten Zugriff auf das lokale Verzeichnis der Nutzer haben. Bis diese einmal entsprechend umgestaltet wurden, werden also wohl viele Flatpaks den Zugriff auf sämtliche lokale Dateien zwingend verlangen, damit sie korrekt funktionieren.

Grafisches Interface

Die Abwicklung all dieser Berechtigungsanfragen soll direkt über den Desktop erfolgen. So arbeiten die GNOME-Entwickler derzeit an einer neuen Version ihrer Softwarezentrale, die solche Anfragen abwickelt, und auch mit neuen Berechtigungen bei Updates umgehen kann. Gleichzeitig soll es möglich sein, Berechtigungen nachträglich wieder zu entziehen. Zu diesem Zweck wird gerade eine neue Abteilung im Kontrollzentrum des Desktops geschaffen. All das soll bereits mit der nächsten GNOME-Version – das für Mitte März vorgesehene GNOME 3.32 – verfügbar sein. Es ist zudem davon auszugehen, dass andere Desktops bald ähnliche Funktionen zum Berechtigungsmanagement integrieren. Auf technischer Ebene werden diese Berechtigungen über ein System namens Portals abgewickelt, das ebenfalls als Desktop-übergreifender Standard ausgelegt ist.

Ein Entwurf für das Berechtigungssystem im GNOME Kontrollzentrum.
Grafik: GNOME

Realitätscheck

Wer so grundlegende Umbauten am Aufbau einer Linux-Distribution vornimmt, muss sich aber natürlich klar sein, dass das alles nicht von einem Tag auf den anderen reibungslos laufen kann. So gibt es derzeit etwa viele Programme noch nicht als Flatpaks. Bei Fedora will man dieses Defizit mit zwei Maßnahmen überbrücken: Einerseits ist dies ein eigenes Flatpak-Repository, wo man Pakete anbieten will, die es auf Flathub, das als zentraler Anlaufpunkt für Drittentwickler gedacht ist, noch nicht gibt. Der zweite Behelf nennt sich rpm-ostree: Damit können dann nämlich sehr wohl auch unter Fedora Silverblue klassische Pakete installiert werden. Diese werden allerdings als Overlay separat vom eigentlichen Systemimage gespeichert. Das Verfahren nennt sich Package Layering, und ist wirklich nur als letzter Ausweg gedacht. Immerhin fängt man sich damit dann erst recht wieder die Probleme eines klassischen Paketsystems ein, was etwa heißen könnte, dass nach einem System-Upgrade plötzlich einzelne Overlays nicht mehr funktionieren – und zu Problemen führen.

Alternativ dazu gibt es dann noch die Fedora Toolbox. Dabei handelt es sich um eine Art Spielwiese für klassische Pakete. Hier werden manuell installierte RPMs in einem gemeinsamen Container betrieben. Langfristig ist das Ziel aber natürlich ganz ohne solche Behelfe auszukommen und alles via Flatpaks abzuwickeln.

Bonusbild mit Katze (rechts unten).
Screenshot: Andreas Proschofsky / DER STANDARD

Testlauf

Wer sich schon einmal mit diesen neuen Konzepten auseinandersetzen will, der ist am besten mit einer aktuellen Testversion von Fedora Silverblue bedient. Das Ziel der Distributionsentwickler ist es für Fedora 30 die Silverblue-Ausführung als vollwertige Alternative zur klassischen Workstation-Ausgabe anbieten zu können. Mittelfristig soll Silverblue dann aber die Workstation komplett ablösen. (Andreas Proschofsky, 3.2.2019)