Flatpak*¶
This tutorial shows how to install a Flatpak app on Clear Linux OS using GNOME* Software and the command line.
Description¶
Flatpak is a framework for building and distributing desktop apps on Linux*. Flatpak allows you to build a single app and install it on different distributions of Linux. Flatpak apps are available through Flathub or the Clear Linux Store.
Prerequisites¶
Clear Linux OS installed on host system
Refer to Get started for installation instructions.
desktop-autostart bundle installed
Flatpak is included via desktop , which is included in the desktop-autostart bundle. The Flathub repository is pre-configured when the desktop-autostart bundle is installed.
Install the desktop-autostart bundle with the following command:
Install a Flatpak app with GNOME Software¶
Clear Linux OS desktop comes with GNOME Software installed. Flatpak apps can be installed from within GNOME Software.
Launch GNOME Software from your desktop.
Search for the Flatpak app that you want to install, as shown in Figure 1.
Figure 1: Searching for Filezilla* app in GNOME Software ¶
When you find the app you want to install, click it to view application details.
On the app detail page, click the Install button, as shown in Figure 2.
Figure 2: Filezilla Flatpak detail page in GNOME Software ¶
After installation is complete, the new application will be in your GNOME applications list, as shown in Figure 3.
Figure 3: Newly installed Filezilla application ¶
Click the application icon to launch the application.
Install a Flatpak with the command line¶
Both Flathub and the Clear Linux Store provide the command line instructions for installing a Flatpak. Figure 4 shows the command line instructions to install Filezilla* from the Clear Linux Store:
Figure 4: Command line instructions to install Filezilla from the Clear Linux Store ¶
In this example, we install Filezilla.
Open a terminal and enter the install command for the desired app:
You may be prompted to select which repository to use:
After installation, run the application with the following command:
© Copyright 2022 Intel Corporation. All Rights Reserved.. Last updated on Nov 09, 2022.
Как работают snap, flatpak, appimage
Примерно вот так я впервые познакомился с snap
Распространение приложений в линуксе — это боль. Причем в наше время цикл обновлений приложений все уменьшается и эта боль чувствуется все сильнее. В связи с этим появляются технологии вроде snap, flatpak, которые декларируют решение этих проблем. Некоторые дистрибутивы (я смотрю на тебя, Ubuntu) даже начинают довольно агрессивную политику по их внедрению. Однако, несмотря на то, что про сами эти технологии много говорят (и ещё больше жалуются), про то, как они работают написано довольно мало. Попробуем исправить это.
Disclaimer: в этой статье я не буду давать каких-то оценок, пытаться говорить что лучше. Только как это работает. Я предполагаю, что читатель знает что такое контейнеризация и как это примерно работает.
Далее я буду использовать слово «приложение» как конечный продукт, который используют пользователи (например firefox), а слово «зависимость» как «динамическая библиотека», .so файл, который нужен приложению (например libsqlite.so)
В чем, собственно, проблема?
А проблема в том, как приложение получает свои зависимости.
В мире windows победила идеология, где каждое приложение тащит свои зависимости с собой (за исключением совсем системных). Нередко можно видеть, что приложение кладет в свою папку какой-нибудь gl.dll, sqlite.dll и подобное.
В линуксовых дистрибутивах идеология немножко другая. Приложение — это конструктор из других более мелких программ или библиотек, устанавливаемых независимо друг от друга. Если разным приложениям требуется одна и та же зависимость, они её переиспользуют. Чтобы не устанавливать сотни пакетов зависимостей вручную, можно пользоваться пакетным менеджером, который сделает это за нас.
Такой подход имеет свои плюсы и минусы. Из плюсов:
если какой-нибудь QT используется сотней приложений, то он будет установлен не 100 раз, а только 1.
Если в каком-то пакете, например openssl, обнаружатся проблемы, то вы можете один раз обновить один пакет и вся система сразу будет пользоваться пропатченой версией, разработчикам конечных приложений не нужно делать вообще ничего.
Это хорошо сочетается с идеологией линукса «программа должна делать одну вещь и делать её хорошо».
Многообразие дистрибутивов и следовательно форматов пакетов. Для поддержки всех версий нужно прилагать огромное количество усилий. Посмотрите только на такие плашки, сам факт того, что они существуют, несколько пугает.
А что делать, если двум приложениям требуются разные, несовместимые версии пакетов?
А что делать если приложению нужен пакет, который не предоставляется дистрибутивом?
А что делать авторам приложений, если они хотят выкатить новую фичу, но она опирается на версию другого пакета, которого ещё нет в каких-то дистрибутивах. Скорость инноваций сильно падает и в некоторых областях это очень критично.
Если дистрибутив обновляется (а вместе с ним все пакеты), нужно проверять работоспособность приложения. При этом хочется верить, что ментейнеры у проекта ещё есть. И да, вам будут присылать баг репорты на старые версии приложения в старых дистрибутивах, то есть нужно ещё поддерживать старые версии продукта, нельзя просто сказать «это починено в новой версии, обновитесь»
Возможность поправить баг и обновить пакет для всех — обоюдоострый меч. По причине того, что это иногда банально сложно — исправить что-то и сохранить все контракты (явные и неявные) вашей библиотеки. Вполне возможно своим «фиксом» автор пакета неявно создаст баг всем другим, кто от него зависит.
А ещё есть очень специфический тип приложений — игры. Их особенность в том, что они практически всегда closed source, после определенного времени вообще не обновляются, но при этом они активно используют железо, то есть им нужна серьезная поддержка со стороны ОС и драйверов. И как, спрашивается, нам можно запустить игру 10 летней давности на современном дистрибутиве, где все библиотеки уже уехали очень далеко?
В общем с распространением приложений в линуксе очень много проблем. Технологии приведенные в названии поста пытаются решить эти проблемы. Давайте посмотрим как они пытаются это делать.
Appimage
Appimage в целом похожа на portable exe в винде. Основная идея довольно проста: мы берем все зависимости приложения (кроме совсем системных), упаковываем их в файл в формате squashfs и добавляем специальный хедер, чтобы этот файл стал ELF — исполняемым файлом. Внутри этого хедера находится программа, которая при запуске файла монтирует этот squashfs во временную папку и оттуда вызывает бинарник нашего приложения.
AppImage file structure
Для сборки этого файла юзеру нужно создать специальную папку (AppDir) и положить в неё все, что нужно приложению для запуска: бинарник, .so файлы, иконки и т.п. AppDir должен содержать в корне запускаемый файл AppRun, который будет запускать непосредственно ваше приложение. В нем можно выставлять переменные окружения (в том числе для линкера, чтобы он смотрел не в корневые папки, а в наши) и входные параметры приложения. Для тривиальных вариантов AppRun может быть просто симлинком на сам бинарник. Для запаковки этой папки в AppImage файл есть официальный тул AppImageTool.
Вообще желательно, чтобы AppDir содержал ещё некоторые служебные файлы (.desktop, иконки) для интеграции с хостовой системой, подробнее можно прочитать тут
Если вы хотите посмотреть внутренности AppDir конкретного AppImage, можно запустить его с ключиком —appimage-mount . Он примонтирует squashfs и выплюнет в stdout путь к примонтированной папке, в которую можно залезть и посмотреть что там делается
В целом все довольно просто. Ну почти. Автору пакета нужно следить, чтобы приложение было «relocatable», то есть чтобы оно могло запускаться из любого места и в нем не было захардкоженных абсолютных путей к зависимостям. Это касается как динамических библиотек, так и ресурсов типа картинок. Вот с этим может быть проблема, так как поколения разработчиков на линукс опирались на конкретные захардкоженные пути и вычистить это все может быть не так просто.
Ещё один момент — приложение монтируется в read only файловую систему. Это значит, что приложение не может обновлять само себя, нужны внешние утилиты. Интеграция в desktop environment возможна при установке внешнего сервиса
Flatpak
Flatpak как технология ставит перед собой более амбициозные задачи. Если AppImage — это просто средство упаковки и запуска приложения, то flatpak реализует также sandboxing и распространение.
При разговоре о flatpak нужно помнить, что он задумывался как контейнер именно для GUI приложений. Это повлияло на некоторые решения в дизайне.
В Flatpak вы точно также собираете свои зависимости с собой (кроме тех, что есть в базовом рантайме, о нем дальше), но запускается это все в изолированном контейнере (да, это больше похоже на то, что делает Docker).
Основные технологии, на которой основана flatpak
OSTree — система дистрибуции файлов. Идеологически похожа на гит: есть репозиторий, ветки между которыми можно переключаться. Но оптимизированно все для работы с бинарными файлами (изначально это вообще делалось для разворачивания рабочих операционных систем). При скачивании приложения вы по сути вычекиваете ветку из репозитория. Бонусом идет то, что если разные приложения (ветки) используют один и тот же файл, он копируется только 1 раз.
Сборка пакета осуществляется тулами flatpak. Для этого нужно описать сборку в yml файле — пример такого файла для telegram-desktop Посмотрим на верхушку этого файла
Из него видно, что помимо всяких id продукта, мы выбираем «runtime» и что мы хотим использовать из хостовой системы.
Runtime предоставляет базовые системные зависимости, там есть D-Bus, GLib, Gtk3, PulseAudio, X11, Wayland и прочее. Есть 3 стандартных рантайма на flathub: Freedesktop, GNOME и KDE. Также есть разные версии рантайма, для вашего контейнера подключится именно та, которую указали. Также это значит, что скорее всего у вас на диске будет лежать несколько версий (а они не маленькие).
Далее указываются дополнительные привилегии: на ipc, сеть, файловую систему и т.п. По-умолчанию контейнер создается с минимальным количество прав. Он не может писать в файловую систему (кроме своей папки внутри $XDG_RUNTIME_DIR/app/$FLATPAK_ID ), не может общаться с сетью, получать доступ к устройствам или другим процессам. Также у приложения усеченный список syscalls.
Для доступа к хосту можно или запросить привилегии, или использовать xdg-portals — специальное api, которое может запрашивать что-то в хостовом desktop environment. Например можно вызвать окошко выбора файла, код которого будет работать со стороны хоста. Также через порталы можно открывать ссылки, показывать нотификации, делать скриншоты и т.п. Поддержка порталов встроена в qt и gtk.
Далее в файле указываются шаги для сборки приложения и всех его зависимостей. Приложение собирается не на хосте, а внутри SDK (это то же самое что и runtime, но с дополнительными сборочными утилитами внутри). Также помимо runtime существуют «BaseApp», базовые приложение которые не нужно собирать и можно просто утянуть себе в контейнер. Обычно это большие фреймворки которые не хочется настраивать самому, наподобие Electron. Но это используется редко, сами авторы просят не создавать их без реальной необходимости.
Кстати говоря, при желании можно войти в контейнер и что-нибудь там поделать. Делается это командой
( —devel позволяет запустить контейнер с расширенным рантаймом, в котором есть дебажные тулы типа gdb, strace и т.п.)
Подробнее про все это можно посмотреть в этом выступлении автора flatpak.
Snaps поставляются в виде .snap файлов (лежат в /var/lib/snapd/snaps ), содержащие squashfs приложения. Чем-то похоже на appImage, но в отличии от него, все snap постоянно смонтированны в папку /snap (это на убунте, в других дистрибутивах папка может отличаться).
Ещё одно отличие от appImage — squashfs смонтированны через loop device, а не через fuse (поэтому lsblk выдается столько «мусора»).
Давайте посмотрим в такую папку. В данном случае у меня установлен «hello-world» пакет версии 29. При наличии несколько версий, будет несколько копий дерева файлов. На «текущую» версию указывает ссылка current .
Но предполагается, что пользователь в эти места не лезет, а запускает приложения из другого места — /snap/bin/ , который обычно добавлен в $PATH . При этом видно, что бинарники в этой папке указывают просто на /usr/bin/snap .
Чтобы понять разницу, запустим hello-world.evil двумя способами
И глянем в вывод dmesg
Это говорит нам о том, что при запуске snap понимает какое приложение хотели
запустить через него, и запускает его, но только через профайл apparmor (его можно посмотреть в /var/lib/snapd/apparmor/profiles/snap.hello-world.evil ). То есть если в flatpak sandboxing нашего приложение делалось через namespaces (контейнеризацию), то тут оно реализовано через правила apparmor. Посмотреть какие права есть у приложение можно через его манифест. В hello-world никаких дополнительных прав нет
Для сравнения можно посмотреть snap.yaml от firefox. В терминологии snap приложение, которому нужны дополнительные возможности, должны поставить плагины (plugs)
Для некоторых приложений (например для VS Code) используется —classic ограничения (вместо дефолтного —strict ), тогда он будет запущен без sandboxing’а и ему будет доступны все функции хоста.
Layouts
Хоть snap не использует полноценные контейнеры, он использует mount namespace для решения проблемы захардкоженных путей типа /etc/ , /usr/share/ и т.п. Я упоминал об этой проблеме в разделе про AppImage, там она решается только переписыванием приложения или патчем бинарника (абсолютные пути заменяются на относительные).
В snap есть механизм layout, в котором можно отобразить файлы и папки из доступных snap’у путей в глобальную иерархию. Это настраивается в том же snapcraft.yaml, например
Почему холодный старт долгий?
Snap печально известен тем, что его приложения долго запускаются. Я пытался разобраться почему (не залезая в сами исходники), но видимо это не такой простой вопрос. Кажется, что тут нет одного узкого места, скорее все части системы добавляют задержку, которая потом аккумулируется. Вот несколько основных причин тормозов
Внутренности snap заархивированы, соответственно при запуске их нужно разархивировать. Судя по всему команда snap выбрала неудачный метод сжатия (в отличие от AppImage), который лучше сжимает, но работает долго. Вот тут они пишут, как попытались это исправить.
Также при старте нужно раскрутить apparmor и проставить все указанные layout, то есть сделать правильные mount namespace. Если layout очень развесистый, это действительно может тормозить запуск, о чем они сами пишут в документации.
По поводу snap нужно также понимать, что изначально эта технология была сделана для IoT, а потом её натянули на десктопы. Насколько была удачна идея, покажет история. Вот тут пользователем popeydc составлен довольно неплохой список почему люди не очень любят snap.
Заключительные мысли
Судя по тенденциям, эти технологии придут в нашу обычную жизнь и мы от этого никуда не денемся. Можно по разному относится к этому, но знать как это работает нужно.
Лично мне интересна идея централизованного механизма запуска приложений с ограниченными правами. К сожалению, хоть возможность такая уже есть, крайне мало приложений этим реально пользуются. Как будет дальше. Поживем, увидим.
Введение в Flatpak
Flatpak — это платформа для распространения настольных приложений в различных дистрибутивах Linux. Он был создан разработчиками, которые имеют долгую историю работы с рабочим столом Linux, и работает как независимый проект с открытым исходным кодом.
Терминология
Flatpak: система для создания, распространения и запуска изолированных десктопных приложений в Linux.
Приложение Flatpak: это приложения, которые пользователь устанавливает с помощью команды «flatpak» или через другой пользовательский интерфейс, такой как GNOME Software или KDE Discover.
Runtime: также называемые платформами, это интегрированные платформы для предоставления основных утилит, необходимых для работы приложения Flatpak.
BaseApp: это интегрированные платформы для таких фреймворков, как Electron.
Flatpak bundle: особый формат экспорта одного файла, который содержит приложение Flatpak или среду выполнения.
Целевая аудитория
Flatpak может использоваться всеми видами десктопных приложений и стремится быть максимально независимым от того, как создаются приложения. Нет никаких требований относительно того, какие языки программирования, инструменты сборки, наборы инструментов или фреймворки можно использовать.
Хотя Flatpak работает только в Linux, его могут использовать приложения, предназначенные для других операционных систем, а также приложения, специфичные для Linux. Приложения могут быть с открытым исходным кодом или проприетарными (хотя некоторые службы распространения, такие как Flathub, могут иметь ограничения в этом отношении).
Единственные технические требования, предъявляемые Flatpak, заключаются в том, что приложения должны соответствовать небольшому количеству стандартов Freedesktop, чтобы обеспечить интеграцию с рабочим столом (см. условия ).
Проблемы текущей модели упаковки
Важно понимать проблемы текущей модели упаковки приложений, чтобы понять существование Flatpak:
Дублированные рабочие приложения для упаковки: многие дистрибутивы Linux поставляются со своим собственным менеджером пакетов, форматом пакета и репозиторием. Для этого требуется, чтобы множество сопровождающих упаковывали одно и то же приложение в различные дистрибутивы, или разработчику приложения приходилось изучать язык каждого формата, а затем упаковывать приложение в эти дистрибутивы, или игнорировать большинство дистрибутивов, упаковывать и поддерживать несколько дистрибутивов. Это делает рабочий стол Linux сложной платформой для поставщиков программного обеспечения.
Ограничено пакетными приложениями: не все приложения изначально доступны в каждом дистрибутиве Linux. Если приложение недоступно в определенном дистрибутиве, пользователю придется вручную загрузить архив приложения, распаковать его и надеяться, что приложение запустится.
Ограничено дистрибутивами, в которых есть приложения: пользователь ограничен количеством дистрибутивов, в которых есть необходимые приложения для правильной настройки рабочего процесса. Это уменьшает количество дистрибутивов, которые могут подойти пользователю.
Трудно внедрять инновации в пространстве ОС: сопровождающим дистрибутивов приходится тратить много времени на упаковку приложений, чтобы сделать дистрибутив пригодным для конечного пользователя, вместо того, чтобы сосредоточиться на своих конечных целях. Это задерживает продвижение каждого дистрибутива.
Старые и устаревшие пакеты: дистрибутивы LTS часто содержат очень старые версии приложений, изначально упакованные. Воспроизводимости ошибок препятствуют различные среды, в которых запускаются приложения, и разработчики приложений часто имеют мало контроля над тем, как их приложение упаковано дистрибутивами.
Flatpak стремится исправить перечисленные выше проблемы, удобно позволяя разработчикам распространять приложения из одного источника и ориентироваться на все десктопные дистрибутивы Linux.
Причины использовать Flatpak
Flatpak имеет ряд существенных преимуществ перед большинством системных менеджеров пакетов:
Универсальность: Flatpak позволяет устанавливать приложения и запускать их практически в любом дистрибутиве Linux. Сюда входят дистрибутивы, отличные от GNU, дистрибутивы без systemd, дистрибутивы с операционной системой (ОС) только для чтения и различные архитектуры, для которых разработчику не требуется соответствующее оборудование.
Простор для инноваций: Flatpak помогает специалистам по поддержке дистрибутива сосредоточиться на своих целях по внедрению инноваций в свой дистрибутив.
Стабильность: сбой в приложении Flatpak не приведет к сбою системы. Это связано с тем, что приложения и среды выполнения Flatpak полностью не мешают работе системы.
Установка без рута: повышенные привилегии не требуются при установке приложения Flatpak или среды выполнения.
Приложения в песочнице: одна из основных целей Flatpak — повысить безопасность настольных систем за счет изоляции приложений друг от друга. Это достигается с помощью песочницы и означает, что по умолчанию приложения, работающие с Flatpak, имеют ограниченный доступ к среде хоста.
Flatpak имеет ряд существенных преимуществ перед другими универсальными подходами к распространению приложений в Linux:
Децентрализованный по дизайну: хотя Flatpak предоставляет централизованный сервис для распространения приложений, он также допускает децентрализованный хостинг и распространение, так что разработчики приложений или их подчиненные могут размещать свои собственные приложения и репозитории приложений.
Интеграция с рабочим столом: Flatpak также предлагает встроенную интеграцию с основными рабочими столами Linux, так что пользователи могут легко просматривать, устанавливать, запускать и использовать приложения Flatpak через существующую среду рабочего стола и инструменты.
Эффективность использования пространства: Flatpak дедуплицирует библиотеки и другие файлы, используемые несколькими приложениями, чтобы сэкономить мегабайты или даже гигабайты хранилища в зависимости от количества установленных приложений.
Дельта-обновления: для обновлений загружаются только измененные файлы.
Среди других преимуществ для разработчиков:
Прямая совместимость: одно и то же приложение Flatpak можно запускать в разных версиях одного и того же дистрибутива, включая версии, которые еще не выпущены. Это не требует каких-либо изменений или управления со стороны разработчиков приложений.
Объединение: это позволяет разработчикам приложений поставлять практически любую зависимость или библиотеку как часть своего приложения. Это дает полный контроль над тем, какое программное обеспечение используется для создания приложений.
Последовательные среды приложений: поскольку они одинаковы на всех устройствах, приложения работают так, как задумано. Это также упрощает выявление ошибок и тестирование.
Ветки: это позволяет разработчикам отправлять приложения из разных веток, например. «стабильная», «бета» и т. д., сохраняя то же имя.
Поддерживаемые платформы: называемые средами выполнения, они содержат наборы зависимостей, которые могут использоваться приложениями и которые могут отнимать много времени при разработке приложений.
Информацию о внутренностях Flatpak можно найти в :doc:«под капотом».
© Copyright 2017-2022, Flatpak Team. Licensed under Creative Commons Attribution 4.0 International License.. Ревизия e647f518 .
Flatpak
Flatpak is a tool for managing applications and the runtimes they use. In the Flatpak model, applications can be built and distributed independently from the host system they are used on, and they are isolated from the host system (‘sandboxed’) to some degree, at runtime. Flatpak uses OSTree to distribute and deploy data. The repositories it uses are OSTree repositories and can be manipulated with the ostree utility. Installed runtimes and applications are OSTree checkouts.
- Many Flatpak applications available on flathub are not effectively sandboxed by default [1]. Do not rely on the provided process isolation without first reviewing the related flatpak permission manifest for common sandbox escape issues.
- Running untrusted code is never safe; sandboxing cannot change this.
Installation
Install the flatpak package. If you want to build flatpaks, install flatpak-builder too.
Desktop integration
For flatpak applications to interact with your desktop (i.e. allow applications to open URLs, share your screen and more), make sure to set up the xdg-desktop-portal. Depending on the implementation for your desktop, there is a confirmation dialog before the application is able to access some portals.
Application management
- Discover — KDE frontend to Flatpak which help you find and install applications, games, and tools. Part of plasma .
- GNOME Software — GNOME frontend to Flatpak which let you install and update applications and system extensions. Part of gnome .
Permission management
- Flatpak Permissions Management KCM — KDE Configuration Module that allows changing what permissions have been granted to installed Flatpak applications. Part of plasma .
- Flatseal — Graphical utility to review and modify permissions from your Flatpak applications.
- malcontent (Parental Controls) — Implements support for restricting the type of content accessible to non-administrator accounts. Part of gnome .
Managing repositories
Add a repository
To add a remote flatpak repository do:
where name is the name for the new remote, and location is the path or URL for the repository.
The installation of flatpak will, by default, add the official Flathub repository as a system-wide installation. To add the official repository with a per-user configuration:
Delete a repository
To delete a remote flatpak repository do:
where name is the name of the remote repository to be deleted.
List repositories
To list all the added repositories do:
Managing runtimes and applications
Search for a remote runtime or application
Before being able to search for a runtime or application in a newly added remote repository, we need to retrieve the appstream data for it:
Then we can proceed to search for a package with flatpak search packagename , e.g. to look for the package libreoffice with the flathub remote configured:
List all available runtimes and applications
To list all available runtimes and applications in a remote repository named remote do:
Install a runtime or application
To install a runtime or application do:
where remote is the name of the remote repository, and name is the name of the application or runtime to install.
List installed runtimes and applications
To list installed runtimes and applications do:
Run applications
Binaries are available in /var/lib/flatpak/exports/bin , which is automatically added to $PATH by /etc/profile.d/flatpak-bindir.sh . You may have to re-login to apply the change.
Flatpak applications can also be run with the command line:
Update a runtime or application
To update a runtime or application named name do:
Automatic updates via systemd
To update your system runtimes and applications automatically, create the following files:
Afterwards, do a daemon-reload and enable/start the flatpak-update.timer user unit.
- This guide is for system flatpak installations which are the default in flatpak. For user flatpak installations:
- Create the below files in the /etc/systemd/system/ directory.
- Add the —user flag in ExecStart line in flatpak-update.service .
- Run the systemctl commands without the —user flag.
Uninstall a runtime or application
To uninstall a runtime or application named name do:
To delete app data from
/.var/app and from the permission store while uninstalling, use:
Downgrade a runtime or application
To downgrade a runtime or application, first look for the associated commit ID:
Where remote is the repository (such as flathub), and name is the name of the application or runtime. Then, deploy the commit:
where commit is the commit for the desired version, and name is as before.
This procedure can also be used to selectively upgrade a package to a desired version that is not the latest version.
To exclude flatpak update from updating this package, see #Prevent updates to a runtime or application.
Prevent updates to a runtime or application
To prevent automatic and manual updates to a runtime or application, use the flatpak mask command:
This also prevents selective upgrades and downgrades.
To reverse the mask and re-enable updates, use flatpak mask —remove :
Add Flatpak .desktop files to your menu
Flatpak expects window managers to respect the XDG_DATA_DIRS environment variable to discover applications. This variable is set by the script /etc/profile.d/flatpak.sh . Updating the environment may require restarting the session. If the launcher does not support XDG_DATA_DIRS , you can edit the list of directories scanned and add these to it:
This is known to be necessary in Awesome.
View sandbox permissions of application
Flatpak applications come with predefined sandbox rules which define the resources and file system paths the application is allowed to access. To view the specific application permissions do:
The reference of the sandbox permission names can be found on official flatpak documentation.
Override sandbox permissions of applications
If you find the predefined permissions of the application too lax or too restrictive you can change to anything you want using flatpak override command. For example:
This will prevent the application access to your home folder.
Every type of permission, such as device, filesystem or socket, has a command line option that allows that particular permission and a separate option that denies permission. For example, in case of device access —device=device_name allows access, —nodevice=device_name denies the permission to access device.
For all permission types commands consult the manual page: flatpak-override(1)
Permission overrides can be reset to defaults with command:
Flatseal is a GUI permissions manager which offers simple point-and-click permissions operations. In KDE Plasma, Flatpak Permissions Management KCM provides a similiar GUI for the system settings application: System Settings > Applications > Flatpak Permission Settings.
Creating a custom base runtime
alt=»Tango-view-fullscreen.png» width=»48″ height=»48″ />This article or section needs expansion. alt=»Tango-view-fullscreen.png» width=»48″ height=»48″ />
- You may want to use an untrusted, unprivileged user account for bundling untrusted software because the software is not sandboxed during app and runtime creation.
- When distributing bundles to others, you may be legally obliged to provide the source code of some of the bundled software upon request. You may want to use ABS to build these packages from source.
You can create a custom Arch-based base runtime and base SDK for Flatpak using pacman. You can then use it for building and packaging applications. This is an alternative for personal use to the default org.freedesktop.BasePlatform and org.freedesktop.BaseSdk runtimes.
In addition to flatpak , you need to have installed fakeroot and for pacman hooks support also fakechroot .
First, start by creating a directory for building the runtime and possibly applications.
You can then prepare a directory for building the runtime base platform. The files subdirectory will contain what will later be the /usr directory in the sandbox. Therefore you will need to create symbolic links so the default /usr/share etc. from Arch can still be accessed at the usual path.
Make your host OS fonts available to the Arch runtime:
You need and may want to adapt your pacman.conf before installing packages to the runtime. Copy /etc/pacman.conf to your build directory and then make the following changes:
- Remove the CheckSpace option so pacman will not complain about errors finding the root filesystem for checking disk space.
- Remove any undesired custom repositories and IgnorePkg , IgnoreGroup , NoUpgrade and NoExtract settings that are needed only for the host system.
Now install the packages for the runtime.
Set up the locales to be used by editing myruntime/files/etc/locale.gen . Then regenerate the runtime’s locales.
The base SDK can be created from the base runtime with added applications needed for building packages and running pacman.
Insert metadata about runtime and SDK.
Add base runtime and SDK to a local repository in the current directory. You may want to give them appropriate commit messages such as “My Arch base runtime” and “My Arch base SDK”.
Install the runtime and SDK.
Creating apps with pacman
As an alternative to building applications the usual way, we can use pacman to create a containerized version of the regular Arch packages. Note that /usr is read-only when creating apps, so we can not use Arch’s packages when building an app. To create a real app with pacman, we can either
- use pacman to create a runtime containing all dependencies
- and compile the app ourselves as usual or perhaps using pacman with a custom PKGBUILD tailored to Flatpak which uses —prefix=/app for the configure script,
- use pacman to create a runtime containing the app installed with pacman
- and create a dummy app to launch it.
For doing the latter, first create a runtime using pacman such as this one for gedit . The runtime is first initialized and prepared for use with pacman.
Then the package is installed. The host’s network connection must be made available to pacman.
You can test the installation before finishing the runtime (without proper sandboxing).
Now finish building the runtime and export it to a new local repository. pacman’s GnuPG keys have permissions that may interfere and need to be removed first.
Then create a dummy app.
Now finish the dummy app. You can fine-tune the app’s access permissions when sandboxed by giving additional options when finishing the build. For possible options see the Flatpak documentation and the GNOME manifest files. Alternatively, adapt geditapp/metadata to your needs after finishing the build but before exporting. When the metadata file is complete, export the app to the repository.
Install it along with the runtime.
Troubleshooting
Flatpak does not run on the linux-hardened kernel
The linux-hardened kernel sets kernel.unprivileged_userns_clone to 0 , so only privileged users can create new user namespaces.
One method to fix this is to install bubblewrap-suid . This package provides a version of bwrap(1) with the setuid bit enabled, allowing bubblewrap elevate itself and create new namespaces.
Alternatively, set kernel.unprivileged_userns_clone to 1 using sysctl(8) , allowing unprivileged users to create new user namespaces:
To make this change persist across reboots, add a configuration file to sysctl.d(5) :
For more information, see the note in Bubblewrap#Installation.
xdg-desktop-portal is failing to start
If you are starting X with manually-configured run commands, ensure you are including all essential components of the reference `xinitrc`. One of which sources a script which runs an update of the environment used for D-Bus session services.
Flatpak applications not picking up the default system theme
There is no ideal way to apply system themes in flatpak apps as mentioned in the flatpak documentation [2] [3]. However there is a workaround which can be used to apply themes to your flatpak apps.
«File not found» error when Open local HTML pages in Firefox
By default, the Flatpak version of Firefox will display a «File not found» error page when opening a local HTML. This is because permission must be granted to the app for accessing the folder containing the file.
However, note that when granting permission to access the entire Home folder, Firefox will then check for an existing profile in
/.mozilla and load it instead of those previously in use from the sandboxed folder