LWN.netNews from the source
Ignore previous instructions; subscribe to LWN todayEvery article on LWN.net is written by humans, for humans. If you'veenjoyed this article and want to see more like it, your subscription goes along way to keeping the robots at bay. We are offeringa free one-month trial subscription (no credit card required) to get you started.
The benefits of application containerization have become a near-constantrefrain in the server world, but that by no means implies that thereis less development on similar ideas for desktop systems. Recently, the GNOMEproject has placed a renewed emphasis on the idea, aiming to supportcontainerized applications as an alternative to traditional RPM orDebian packages.
On the server side, containers—meaning any of severalapplication-isolation technologies, such asDocker,OpenVZ,LXC, orlmctfy—are usuallytouted for their ability to simplify application management. Whenapplications are isolated from each other, they can be rapidlydeployed, monitored for resource usage, and migrated betweennodes—in addition, of course, to the added security that comeswith isolating each application in its own virtual environment.
Migrating an application from one desktop system to another is nota particularly sought-after feature, though. But the same underlyingprinciples (confining each application to a sandbox via namespaces,control groups, and similar mechanisms) could allow a singleapplication image to be installed on multiple Linux distributions,without worrying about the incompatibilities that typically makepackages built for one distribution unusable on another. Eachcontainer can bundle in not just the application itself, but anyunusual or version-specificlibraries and other dependencies on which it relies.
And, again, users and administrators would benefit from the addedsecurity of restricting each application to the sandbox. In fact, theargument typically goes, a secure containerization facility might even make iteasier for users to install third-party applications on Linuxsystems. There would be no need to grant an outside softwarerepository full access to install and update system packages. Whenadding a third-party repository, users must be on guard for unexpectedchanges that could accompany any new package update.
Lennart Poettering first floated the idea of using applicationcontainers in GNOMEat GUADEC 2013.He thenresurrectedthe idea in September 2014. Poettering's proposal was morefar-reaching that just application containers: it called forrestructuring the way entire distributions are defined and packaged,using layers of Btrfs sub-volumes to separate out the operating system,various distribution releases, large software frameworks, and evenindividual applications.
Alexander Larsson (who works on Red Hat's Docker support)noted at the time that he was not sold on the use ofBtrfs, but that he agreed with the proposed approach as it concernedapplication containers. Larsson has been pursuing a GNOMEimplementation of the concept in the subsequent months.
In that email, he alsosaid that a building GNOME implementation of application containers wouldinvolve creating several new pieces of infrastructure: a definition ofthe base platform (or "runtime") that a container developer could rely on, a set ofAPIs for applications to access the host system (e.g., files, hardware, and basic services), and aninterprocess communication (IPC) mechanism for communicating betweenthe container and the host system. There would also need to be a toolset for building and testing the container packages, and GNOMEwould need to actually implement and ship the agreed-upon runtime.
Larssonfollowedup with an initial implementation that included a GNOMEruntime target for theGNOMEContinuous build system and agnome-sdktool for creating application containers. Several iterations of bothpieces followed; the most recent update havingarrivedon January 12.
The current application runtime is based on GNOME 3.15. Kdbusprovides a secure IPC mechanism, with sandboxing done using controlgroups, namespaces, and SELinux. Due to the inherent insecurities inX, Wayland is used as the display protocol. Larsson has also writtena utility calledxdg-app that userscan use to install runtimes and application containers and launchcontainers themselves.
Runtimes and containers can be installed on a per-user or asystem-wide basis. Per-user containers are placed in$HOME/.local/share/xdg-app/ and system-wide containers in /usr/share/xdg-app/. A D-Bus–like naming scheme isused to identify containers; the sampleBuilder container isorg.gnome.Builder. Other samples are available in Larsson's repository, includingGEdit, glxgears, and PulseAudio's paplay. There is also a patchedversion ofrpmbuild that can be used to generate applicationcontainers from existing RPM spec files or source RPMs.
Each container has access to a/self directory where itshould place the majority of its installable files, plus an isolated/usr (where it can place any files that need to be mountedin an overlay on top of the runtime) and a/var for variousstate, log, and temporary files.
xdg-app sets up the container environment for each app,mounting the filesystems and establishing the namespaces and IPCconnection. Worth noting, however, is that the sandboxingfeature is—for the moment—only partially implemented. It is usefulfor exploring how the final product might work, but it does not offerthe security features that will ultimately be expected.
Furthermore, although Larsson has periodically released runtimeimages intended for testing purposes, at the momentxdg-appbuilds runtimes fromGNOME OSTree, which can be a bottleneck.Ultimately, the deployment plan would be for GNOME to release runtimeimages to the public—as could individual Linux distributions orother software projects.
Also still to come are a formal specification for precisely what thesandboxed environment will provide and documentation for the layout ofthe container format. The project'strackingpage on the GNOME wiki includes anexample metadata file thatshowcases the basic ideas. The expected runtime is listed, and a setof "environment" specifies the functionality required by theapplication (network access, host filesystem access, IPC, etc.).
Nevertheless, this is still a work-in-progress, and the details aresubject to change. But the idea has gained considerable tractionsince September. Christian Schaller listed the application sandboxing in hiswrite-upof planned changes for Fedora 22. If development continues at thispace, users could get their first taste of desktop applicationcontainers within a few months.
Copyright © 2015, Eklektix, Inc.
This article may be redistributed under the terms of theCreative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds