Triathlon

Design and Security

RPM and DEB packages store content in the filesystem with root privileges after installation. It is then up to you or an init system to execute the new program with the desired rights. Without additional user intervention, the application runs in the same namespace as the kernel and all other processes. Isolation from the rest of the environment only occurs if you take care of this yourself with tools such as chroot [8], SELinux [9], or AppArmor [10].

Flatpak's structure, on the other hand, allows a completely different approach. Packages are primarily aimed at desktop use and require a run-time environment. It provides basic content for an application's operation and takes up little space on the hard disk (~150-300MB). A list of existing environments can be found on the project's website [11].

A developer must build each package against one of these run times. It then runs wherever the run-time environment in question is installed. During the installation, the system detects whether the required run time already exists and follows it up if necessary. A system can contain several run-time environments in different variants, which enables applications bundled with Flatpak to be kept in different versions. If a program requires additional dependencies beyond the run time, these are included in the package.

The installation of both the run time and the application requires root privileges. However, because a Flatpak package runs in its own, isolated environment, you can launch the included program without extended privileges.

Flatpak uses various well-known technologies in the background, which are also used in the container environment. Bubblewrap [12], for example, ensures that the software runs in its own namespace [13] in the context of the current user. This means that it only sees itself and the required run-time environment.

Techniques such as cgroups [14] strictly regulate access to files, the network, the graphical user interface (GUI), and various subsystems. Using predefined interfaces from the portal APIs [15], an application running in the sandbox can access resources on the host if required (Figure 1). This approach is what prompts people to refer to Flatpak as the "desktop container."

Figure 1: Flatpak package topology is reminiscent of typical container architectures [16].

Snaps works in a similar way. The software bundles require the minimal operating system Ubuntu Core, which you store on the local system using classic Debian packages (Figure 2). The environment contains slightly more than 80MB of basic components. As soon as you install the first snap, the system automatically retrieves the missing parts.

Figure 2: The logical structure of Snap, where Ubuntu Core is shown here as os snap [17].

Because Ubuntu Core comes from official sources and is trusted by the system, it runs this run-time environment in the normal namespace. The applications themselves, on the other hand, run in a closed namespace, and the use of resources is limited by cgroups.

Users install the snaps with sudo or root privileges, whereas running the software itself does not require extended rights. The Snap package format is equally suitable for systems with and without a GUI.

AppImage differs in some features from its rivals Snap and Flatpak. A package is a compressed image file that you download and run without extended privileges (Figure 3). Each image contains all dependencies for the respective software.

Figure 3: Logical structure of the AppImage format.

If you use such a package, the system temporarily mounts the image in the package as read only and starts the application packaged therein, with no installation as for RPM and DEB packages. By default, applications from AppImage packages are not isolated from the rest of the system. If you want to use a sandboxing method [18], you need optional additional programs. You will find instructions on GitHub [19].

Some developers behind the AppImage project have also launched the appimaged [20] daemon, which scans certain user directories for AppImage files, registers them with the system if so desired, and executes images in a sandbox if required. The typical target group for programs in the AppImage format are users who run their systems in a GUI.

Independent of Distribution

Flatpak was designed from the beginning to work on popular distributions like Arch Linux, CentOS, Debian, Fedora, openSUSE, Red Hat, and Ubuntu. Originally, it was intended that users would search the Internet for software sources themselves.

One source is provided by the flatpakref file in a classic format; it contains various information about the package, such as a URL to the content. Flatpak's package management then uses this file to download and set up the corresponding package.

In the meantime, however, developers have enhanced the tools for managing packages with the option of adding remotes or repositories, which you can then browse. Retrieving a package then works in the usual way: First run the corresponding command to search for a program, and install it with the package manager (Figure 4).

Figure 4: Flatpak makes it easy to install and run the Signal messenger.

Once installed, it is possible to list, update, and remove Flatpaks. You can also launch an application using the appropriate tools. Both individual websites (e.g., from software vendors) and repositories such as Flathub [21] serve as software sources.

The Snap package format and the associated Snappy manager originally focused on Ubuntu as a platform. The long-term goal was to replace DEB packages, as well as Apt and Aptitude. In June 2016, developers ported the package manager and format to further Linux distributions [22]. Since then, Arch Linux, CentOS, Debian, Fedora, Gentoo, openSUSE, and Red Hat have the ability to use Snap packages.

On each distribution, Snappy can read the metadata of Snap packages and implement certain rules depending on the distribution (e.g., in the security sector). For this reason, such a system does not necessarily need to include AppArmor for applications to launch from packages.

The Snap tools interact with the snapd daemon, which you use to retrieve packages from official sources or stores. Canonical's official source for snaps is the Ubuntu Store (for an unofficial source, visit uApp Explorer [23]). If you log in to the store with the package manager, you can install packages without sudo or root rights.

If you can retrieve packages with the .snap file extension by other means, you can install them from the local filesystem. Snappy supports a variety of actions for packages, including the usual suspects such as install, search, update, list, and remove. Snaps store commands on the local system that let you access the freshly installed application directly (Figure 5).

Figure 5: Installing and running the snap for the hello application on Ubuntu 16.04.

Unlike RPM, DEB, or Snap, for a long time, AppImage did not have a classical package manager to let users search for and install software. Instead, you obtained a package from the vendor's website or some other provider. That was the inventor's idea: On the project's website, you can read that the package format aims to obtain software directly from the vendor and not from repositories that inevitably offer outdated versions at some point. However, the project itself is eroding this concept: On the GitHub page, you will find at least one list of prebuilt images [24].

Once downloaded, you can move the file to the desired location and run it like any other application. Neither downloading the packages nor executing them requires special privileges.

As mentioned above, appimaged has become an optional tool that will be developed in the long term toward package management. Until the software is mature and officially integrated, most users will probably rely on the browser to retrieve applications. However, users have no way to update or list already downloaded AppImage packages – these tasks are entirely up to you.

AppImage supports all major distributions, including Arch Linux, CentOS, Debian, Fedora, openSUSE, Red Hat, and Ubuntu. You call programs packed by AppImage directly (Figure 6).

Figure 6: Under AppImage, you can download and run applications directly, as shown here with Cantata.

Acceptance

The degree of dissemination of the three modern formats is difficult to estimate, because there are no official figures and statistics from the respective projects. In addition to RPM and DEB packages, many software manufacturers now offer downloads as a Flatpak, Snap, or AppImage on their own websites, because forum users (on GitHub in particular) are increasingly asking for them.

The few repositories that exist (if at all) for the new packages contain only a few hundred – in one case, well over a thousand packages. If you want to manage a desktop or server system exclusively with new formats, you are at a disadvantage at the moment: The frequently used programs are usually only available in the previously known package formats. Canonical does offer the Snapcraft tool for creating snap bundles from existing Debian packages. You can create packages directly on the website.

If you also want to upload software in snap format to the central source for snap packages, the Ubuntu Store, you must first sign a contributor license agreement with Canonical. Because such agreements usually act as a deterrent to developers from the open source community, many do not make an entry in the official directory or avoid the format altogether.

Flatpak and AppImage also offer tools for creating packages. Unlike Snap, they do not provide an official converter for RPM or DEB packages, because the classic formats usually contain specific instructions for the distributions, which are difficult, if not impossible, to translate into cross-platform procedures.

If you want to upload your Flatpak package to one of the few existing repositories, you do not usually need to keep any special features in mind. After all, AppImage file creators can add their package to unofficial lists that circulate on the Internet and form a kind of image file yellow pages.