After a year and a half of development, a new stable branch of the Flatpak toolkit 1.18 has been released, providing a system for building self-contained packages that are not tied to specific Linux distributions and are executed in a special container, isolating the application from the rest of the system. Support for running Flatpak packages is available for Fedora, CentOS, Debian, Arch Linux, Gentoo, Linux Mint, Alt Linux, and Ubuntu. Flatpak packages are included in the Fedora repository and are supported in the native application management programs GNOME and KDE.
Key innovations in the Flatpak 1.18 branch:
- Support for conditional permissions has been implemented, allowing the system to check for specific capabilities during permission requests. For example, when accessing input devices, instead of using "--device=all", one can request the permission "--device-if=all:!has-input-device --device=input", which will grant access only to input devices or fall back to access to all devices if selective access is not supported by the runtime. Similarly, access to USB devices can be requested with the conditions "has-usb-device" and "has-usb-portal".
- Access to the device /dev/ntsync has been enabled for interfacing with
the NTSYNC kernel module, which implements a set of synchronization primitives used in the Windows NT kernel and significantly enhances the performance of Windows games run with Wine. - Support for VA-API for hardware-accelerated video decoding has been included for Intel Xe GPUs.
- Access to the /dev/kfd (Kernel Fusion Driver) device has been provided using permissions granted for DRI devices. The kfd driver implements an interface for executing calculations directly on AMD GPUs from applications that use AMD ROCm, HIP, and OpenCL.
- Support for using command line options to pass access to directories into isolated applications has been added.
- Support for the directory "preinstall.d", which defines a list of pre-installed Flatpak applications (to include Flatpak applications in the operating system), has been added.
- Direct installation of applications from OCI container images, which can be loaded from personal OCI repositories and local archives, has been allowed.
- Support for the URI "flatpak+https://" has been added to the command "flatpak install --from".
- The command 'flatpak run' has been added with the '--clear-env' option to clear environment variables before launching the application.
- The ability to export the root directory of the host environment into an isolated application environment with access through the /run/host/root directory has been provided.
- The ability to output the results of command execution in JSON format has been added.
- The isolation of the build environment has been strengthened — the command 'flatpak build' no longer provides access to the host by default.
- The 'reinstall' command has been added for reinstalling dependencies (bundle).
- Default D-Bus settings have been moved from the /etc directory to /usr.
- Startup time has been reduced when using the fish shell.
- A function has been added to libflatpak to retrieve information about the creation time of the configuration, allowing applications like GNOME Software to determine that their cached data needs updating.
- The build option http_backend has been removed, and the libcurl library has been implemented for HTTP/HTTPS downloads instead of libsoup2.
- By default, the use of escape sequences to indicate the progress of operations is enabled.
- Permissions to access devices are now allowed to be passed to nested sandbox environments created through Flatpak portals.
- For applications delivered as OCI images, the 'extra-data' mechanism has been implemented, allowing for example the playback of h.265 video in Flatpak packages on Fedora Linux.
- Support for dependency compression (OCI bundle) using the zstd algorithm has been added, which compresses data more efficiently. By default, gzip is still used for compression, ensuring maximum compatibility.
Flatpak simplifies the distribution of software not included in the standard repositories of distributions by preparing a single universal container, freeing developers from the need to create separate builds for each distribution. For users concerned about security, Flatpak allows dubious applications to run in a container, providing selective access to only the necessary network features and user files. Users interested in the latest updates can install the most recent test and stable releases of applications without needing to alter their system. For example, Flatpak packages are available for LibreOffice, GIMP, Inkscape, Kdenlive, Steam, 0 A.D., Visual Studio Code, VLC, Slack, Telegram Desktop, Android Studio, and more.
To reduce size, the package includes only application-specific dependencies. Basic system and graphical libraries (GTK, Qt, GNOME and KDE libraries, etc.) are provided as plug-in standard runtime environments. The key difference between Flatpak and Snap is that Snap uses the main system environment components and isolation based on filtering system calls, while Flatpak creates a separate container from the system and operates large runtime sets, providing not packages as dependencies but standard system environments (for example, all the libraries needed for GNOME or KDE applications).
In addition to the standard system environment (runtime) installed via a special repository, additional dependencies (bundle) required for the application to work are provided. Together, the 'runtime' and 'bundle' form the container's core, with 'runtime' installed separately and bound to multiple containers, thus avoiding duplication of common system files across containers.
Multiple different 'runtimes' (GNOME, KDE) or multiple versions of the same 'runtime' (GNOME 50, GNOME 49) can be installed in one system. An application container as a dependency uses binding only to a specific 'runtime', without regard for the individual packages that make up the chosen 'runtime'. All missing components are packaged directly with the application. When creating a container, the contents of the 'runtime' are mounted as the /usr partition, and the 'bundle' is mounted in the /app directory.
The core of the 'runtime' and application containers is formed using OSTree technology, where the image is atomically updated from a Git-like repository, allowing version control methods to be applied to distribution components (for example, the system can be quickly rolled back to a previous state). RPM packages are translated into the OSTree repository using the rpm-ostree layer.
Selective installation and updating of packages within the working environment is not supported—the system is updated not at the level of individual components, but as a whole, atomically changing its state. Tools are provided for the incremental application of updates, eliminating the need for a complete image replacement with each update.
The isolated environment created is independent of the distribution used and, with proper package configuration, does not have access to user files and processes or the main system, and cannot directly access hardware, except for output via DRI. Graphics output and input organization are implemented using the Wayland protocol or through X11 socket forwarding. Interaction with the external environment is based on the DBus messaging system and a special API called Portals.
For isolation, Bubblewrap layer and traditional Linux container virtualization technologies are used, based on cgroups, namespaces, Seccomp, and SELinux. When creating a package, isolation can be disabled, which some developers of specific packages take advantage of to gain full access to the filesystem and all devices on the system.
Source: opennet.ru
