Sandbox в flatpak - объясните на пальцах

Собранные пакеты могут установить разрешение на чтение некоторых директорий или вообще всей системы по умолчанию.

Это можно исправить с помощью flatpak override --filesystem=something tld.site.package. Документацию сам знаешь, где найти.

Собранные пакеты могут установить разрешение на чтение некоторых директорий или вообще всей системы по умолчанию.

А где посмотреть какие есть разрешения у пакета?

Пробую:

flatpak  permission-show org.mozilla.firefox
flatpak  permissions org.mozilla.firefox

Но в ответ пустота.

А где посмотреть какие есть разрешения у пакета?

commagray@Canterlot ~> flatpak info --show-permissions org.audacityteam.Audacity
[Context]
shared=ipc;
sockets=x11;wayland;pulseaudio;
devices=all;
filesystems=host;

[Environment]
ALSA_CONFIG_PATH=

У Audacity здесь доступ ко всей системе.

Спасибо увидел:

flatpak  info --show-permissions org.mozilla.firefox
[Context]
shared=network;ipc;
sockets=x11;pulseaudio;
devices=all;
filesystems=xdg-download;/tmp;
persistent=.mozilla;

[Session Bus Policy]
org.freedesktop.ScreenSaver=talk
org.gnome.SessionManager=talk
org.mpris.MediaPlayer2.org.mozilla.firefox=talk
org.gtk.vfs.*=talk
org.a11y.Bus=talk
org.freedesktop.Notifications=talk
org.freedesktop.FileManager1=talk

[System Bus Policy]
org.freedesktop.NetworkManager=talk

Заметь ещё, что /etc/passwd в песочнице и системный — разные.

Кстати да...чето я сразу не обратил внимание, наверное оно в сандбоксе всетаки было

Именно вот по этой причине что я не контролирую то что там мейнтейнер в сандбоксе наворотил - я юзаю свою костыльную песочницу на базе bubblewrap’а, на котором, кстати flatpak и основан.

Зочем, если можно просто оверрайтить настройки песочницы?

Просто я знатный велосипедо-строитель. Сейчас, в принципе, уже и не зачем, а в те стародавние времена когда я начинал делать свой велосипед flatpak нифига не умел ещё толком (а вот bubblewrap при этом как раз таки почти не изменился).

Сейчас у меня все мои окружения для разработки, отладки и тестирования на этой самодельной песочнице основаны, я даже запилил отдельный форк fakeroot’а специально для user-namespace’ов (оригинал не на 100% совместим) и механизмы имитации «рута» на его основе, так что как минимум дебиан, убунта и opensuse (другие дистры я пробовал не так много) вообще ставятся в такую песочницу штатными методами прямо с правами обычного пользователя: можно доустанавливать и удалять пакеты, и.т.д. Прям такой LXC\Docker курильщика на минималках получился.

Наверняка я смогу всё это сделать и на flatpak’е, но переносить все эти наработки на новую «платформу» у меня уже просто нет времени и сил.

Что то давно не было постов про виндовый Dllhell... :(

Сейчас место стоит копейки, так что если софтина за собой тянет все либы - это не так страшно как 20 лет назад...а вот когда из-за установки (обновления) одной софтины, надо по зависимостям пол системы обновлять (да да да, регуальные обновления раз в неделю, я знаю) - это коненчо то еще счастье...

Ахаххахааха, до флатпака говорили в точности наоборот :)

Кто говорит? Я точно не говорил, когда познакомился с linux в 2006 году у меня было 300mb в месяц трафика и нельзя было просто скачать и запустить софт (что пакетом, что для сборки нужно было докачивать зависимости, причем опеределнных версий), так что полноценное знакомство пишлось отложить на 2 года, когда перебрался в город с безлимитным интернетом.

Что то давно не было постов про виндовый Dllhell… :(

Можем организовать, почему нет.

Допустим, надо собрать плагины под винду, ну например в формате VST. Допустим, что наш плагин использует относительно сложную математику, то же быстрое преобразование Фурье, которое должно работать с минимальными затратами ресурсов в риалтайме (это же VST). Естественно, на коленке это писать никто не будет - есть библиотека fftw3, которую мы можем подключить к плагину и вуаля.

И вот тут нас ждет dll hell и сатанинский гогот.

В Linux это сделать не составляет вообще никакой проблемы, плагин линкуется с libfftw3, как - добавлением ключа -lfftw3 для gcc при линковке.

Если соответствующий пакет стоит в системе, линковщик найдет библиотеку, слинкует с ней и плагин будет работать везде где установлен нужный пакет.

Но в винде - хрена с два. Во-первых, а откуда в винде мы будем брать fftw3.dll? Пакетной системы то нет. И любители Chokolatey в данном случае идут лесом. И вот, в Visual Studio нам подвезли пакетную систему - NuGet. Ищем и радостно находим там fftw3. Казалось бы, но это проблемы не решает!

Во-первых, то что всунуто в NuGet легко может быть собрано с другим C++ runtime чем используемый разработчиком в данный момент. Это не нормальный линукс, где все атуализируется под текущую версию тулчейна. Но это еще фигня.

Линкуем с нужной dll, загружаем плагин и опа - он не работает! Вот так - не видит dll! Куда нам надо ее положить?

В винде есть общее хранилище - system32 (куда надо класть, ВНИМАНИЕ 64-битные библиотеки, шестидесяти четырех прописью), и есть SysWOW64 куда надо класть 32-битные библиотеки (yes, thirty-three bits!). Логично то как.

Но это зашквар и возврат к тому самому DLL HELLL о котором ты просил. Очевидно, что в современной винде dll кладут в папку к программе, чтобы ничего чужого не затереть. Но с плагинами то что делать?

Винда ищет dll в папке, из которой программа запущена. А плагин то лежит совсем в другой папке! И один плагин подходит к десятку хостовых приложений, нам что, теперь пихать dll каждому возможному хосту в его папку? Это надо упороться грибами сначала.

И вот мы берем исходники fftw3, которые в 5 раз больше по объему чем наш плагин, добавляем их тупо в солюшн себе и все это линкуем статически. И так с каждой нужной библиотекой, молясь чтобы она не была завязана на winpthreads, с которым в NuGet вообще беда.

Вот это я называю ад для разработчика.

flatpak info --show-permissions org.mozilla.firefox

Тоже недавно интересовался контейнерами и альтернативными пакетными менеджерами, вроде flatpak и snap. Ты дальше стал разбираться? Как оно ограничивает доступ к FS - понятно, через bubblewrap. А как оно ограничивает работу с D-Bus? Вот этого я не нашёл. Там какой-то прокси внутри контейнера?

А как оно ограничивает работу с D-Bus? Вот этого я не нашёл. Там какой-то прокси внутри контейнера?

Нет, на столько я не копал, ограничился доступом к сети и fs.

Нет, на столько я не копал, ограничился доступом к сети и fs.

Я думаю, как бы механизмы от Flatpak прикрутить к AppImage... А то там штатного средства никакого нет вообще, а FireJail выглядит старым и неудобным. В результате всё на доверии к автору ПО.

DawnCaster выше говорил, что на основе bubblewrap песочницу замутил, может подскажет