Snaps verbinden

Da die Anwendungen in den Sandboxen abgeschottet laufen, kann ein Datenbank-Client in einem Snap nicht die MySQL-Datenbank aus einem anderen Snap nutzen. Um dies dennoch zu ermöglichen, verwenden die Snaps sogenannte Interfaces: Ein Dienst in einem Snap bietet einen Slot an, mit dem sich andere Snaps über einen Stecker ("Plug") verbinden können. Nur Anwendungen mit dem passenden Interface können miteinander kommunizieren. Im Beispiel könnte die MySQL-Datenbank ein Interface namens "mysql" besitzen, das einen Slot namens "database" anbietet. Die Client-Anwendung wiederum unterstützt ebenfalls das Interface "mysql" und besitzt einen Plug namens "db", der in den Slot "database" passt. Welche Interfaces mit welchen Slots und Plugs ein Snap-Paket anbietet, notiert der Ersteller des Snap in "snap.yaml".

Es gibt mehrere vordefinierte Interfaces, über die sich das Snap unter anderem mit dem gastgebenden Linux-System verbinden darf. So kann etwa über das Interface "network" eine Anwendung als Client auf das Netzwerk zugreifen. Analog lassen sich Server über das Interface "network-bind" erreichen. Einige dieser Interfaces verbindet der "snapd"-Daemon bereits bei der Installation des entsprechenden Snaps. Dies gilt beispielsweise für "network" und "network-bind". Manuell lassen sich zwei Snaps über das Kommando »snap connect Snap:Plug Snap:Slot« verbinden. Eine Aufstellung aller existierenden Interfaces findet sich unter [3].

Nachteile von Snaps

Snaps klingen erst einmal verlockend, bringen aber selbst Probleme mit. Da in einem Snap alle von der Anwendung benötigten Abhängigkeiten stecken, bläht sich das Snap entsprechend auf. Von mehreren Anwendungen genutzte Bibliotheken landen mehrfach auf der Festplatte. Letztlich sind bei Snaps die Anwendungsentwickler dafür verantwortlich, alle mitgelieferten Bibliotheken auf dem neuesten Stand zu halten. Reagieren die Entwickler nicht schnell und gewissenhaft, können unbemerkt Sicherheitslücken zurückbleiben. Liegt eine Bibliothek in einer neuen Version vor, erzwingt das ein Update aller Snaps, in der sie enthalten ist.

Fällt der "snapd"-Daemon aus, ist das komplette Paketsystem lahmgelegt, er mutiert somit zum Single Point of Failure. Der "snapd"-Daemon kann zudem derzeit immer nur einen Store anzapfen. Standardmäßig ist das der von Canonical betriebene Ubuntu Store, eine Alternative gibt es noch nicht. Wer einen eigenen Store aufsetzen möchte, muss den dazu passenden Server selbst implementieren, die Software hinter dem Ubuntu Store hält Canonical unter Verschluss. Der Quellcode eines minimalistischen Beispiel-Stores lag für einige Zeit auf GitHub. Durch die zahlreichen Änderungen an Snap funktionierte diese Implementierung jedoch nicht mehr, sodass der Entwickler schließlich den Quellcode wieder entfernte. Im Kern handelt es sich bei einem Snap Store um eine einfache Web-Anwendung, die via REST-API die entsprechenden Snaps ausliefert.

Die Zahl der im Ubuntu Store angebotenen Snaps war zum Redaktionsschluss überschaubar. MySQL und viele andere wichtige Anwendungen fehlten, im vorhandenen Programmangebot fanden sich zudem häufig veraltete Versionen. Langfristig möchte Canonical offenbar auch kostenpflichtige Snaps anbieten, zumindest ist "snap" darauf vorbereitet (mit dem Kommando »snap buy« ).

Den vollen Funktionsumfang der Snaps gibt es derzeit nur unter Ubuntu. Auf allen anderen offiziell unterstützten Distributionen ist zumindest der sogenannte Devmode aktiv. Verletzt in ihm eine Anwendung eine Sicherheitsregel, produziert das lediglich eine Warnung im Syslog. App­Armor setzen zudem nicht alle Distributionen ein, die speziellen Patches von Canonical zur Härtung des Linux-Kernels gibt es auch nur für Ubuntu.