Скрытое содержимое Flatpak🔗

На этой странице представлен обзор внутренней работы Flatpak. Хотя не обязательно знать это, чтобы использовать Flatpak, некоторым это может показаться интересным. Знание об архитектуре Flatpak также помогает лучше понять, как и почему она работает именно так, с точки зрения пользователя и разработчика приложений.

«Git for apps»🔗

Flatpak построен на основе технологии под названием OSTree, которая находится под влиянием системы контроля версий Git и очень похожа на нее. Как и Git, OSTree позволяет отслеживать версионные данные и распределять их между различными репозиториями. Однако там, где Git предназначен для отслеживания исходных файлов, OSTree предназначен для отслеживания двоичных файлов и других больших данных.

Таким образом, внутри Flatpak работает аналогично Git, и многие концепции Flatpak аналогичны концепциям Git. Как и Git, Flatpak использует репозитории для хранения данных и отслеживает различия между версиями.

В Flatpak каждое приложение, среда выполнения и расширение - это ветка в репозитории. Тройная идентификация, например com.company.App/x86_64/stable, является ссылкой на эту ветку. Результатом процесса сборки Flatpak является каталог файлов, который привязан к одной из этих веток.

Когда приложение устанавливается с помощью Flatpak, оно переносится с удалённой в новую ветку в локальном репозитории. Затем генерируются ссылки, которые указывают из нужных мест в файловой системе на файлы приложения в репозитории (это жесткие ссылки, которые быстро разрешаются и освобождают дисковое пространство, занимая мало места на диске). Другими словами, каждое установленное приложение хранится в локальном репозитории управления версиями, а затем сопоставляется с локальной файловой системой.

Таким образом, отслеживание версий является основной частью архитектуры Flatpak, и это делает обновление программного обеспечения до последней версии очень эффективным. Управление версиями также делает возможными откаты, поэтому при необходимости легко вернуться к предыдущей версии.

Хранение приложений в локальном репозитории OSTree имеет и другие преимущества. Например, он позволяет удалять дубликаты файлов, хранящихся на диске, поэтому один и тот же файл, принадлежащий нескольким приложениям (или средам выполнения), сохраняется только один раз.

This blog post explains the underlying structure of a Flatpak repository in more detail.

Conditional permission system🔗

Since Flatpak 1.17.0, conditional permissions allow permissions to be granted only when certain runtime conditions are satisfied, with fallback to unconditional grants for compatibility with older versions.

Permissions are internally represented as:

  • unconditionally allowed or denied

  • a reset flag indicating whether the current layer overrides rules from lower layers

  • a set of conditional rules under which the permission may be allowed

For example:

  • --socket=NAME unconditionally allows the permission and resets any previously defined rules for that permission

  • --nosocket=NAME unconditionally denies the permission and resets any previously defined rules

  • --socket-if=NAME:CONDITION adds a conditional rule without resetting existing rules

Conditions may be negated using !.

Multiple conditional rules can be specified for the same permission. In this case, the permission is granted if any condition evaluates to true.

Duplicate conditions are ignored. The order of conditions does not affect evaluation.

If no conditional rules are present, the permission is granted only if it is unconditionally allowed.

If conditional rules are present, the permission is granted if any condition evaluates to true, and denied otherwise, unless it is also unconditionally allowed.

If an unconditional entry follows a conditional entry for the same grant in commandline flags, the earlier unconditional entry is treated as backwards compatibility fallback and does not affect the final permission state.

A --socket-if=NAME:CONDITION is written in the metadata as:

sockets=NAME;if:NAME:CONDITION;

Permissions are written to metadata using the following rules:

  • Unconditionally allowed permissions are written as NAME

  • Unconditionally denied permissions are written as !NAME

  • Conditionally allowed permissions are written as:

    • unconditional NAME entry for compat

    • if:NAME:CONDITION entries

If the permission resets previously defined rules, an explicit !NAME entry is written first, followed by the unconditional NAME entry and then the if:NAME:CONDITION entries. This is omitted when saving an application’s own metadata, as opposed to overrides.

When parsing metadata, a non-negated unconditional NAME entry appearing before a if:NAME:CONDITION entry is treated as a compatibility fallback and does not affect the final permission state. Eg. sockets=x11;if:x11:!has-wayland; is effectively treated as if:x11:!has-wayland in Flatpak versions supporting conditional permissions.

Базовые технологии🔗

Flatpak использует ряд уже существующих технологий. К ним относятся:

  • Утилита bubblewrap из Project Atomic, которая позволяет непривилегированным пользователям устанавливать и запускать контейнеры, используя такие функции ядра, как:

    • Namespaces

    • Bind mounts

    • Seccomp rules

  • systemd для настройки контрольных групп для песочниц

  • D-Bus, - хорошо зарекомендовавший себя способ предоставления высокоуровневых API для приложений

  • The OSTree system for versioning and distributing filesystem trees

  • Формат OCI из Open Container Initiative <https://opencontainers.org/>`_ в качестве альтернативы OSTree, используемой инфраструктурой Fedora <https://blog.fishsoup.net/2018/12/04/ flatpaks-in-fedora-now-live/>`__

  • Flatpak может использовать OSTree или OCI для однофайловых пакетов.

  • Appstream - метаданные, предназначенные для того, чтобы приложения Flatpak хорошо отображались в приложениях центра программ