Доступен выпуск инструментария для организации работы изолированных окружений Bubblewrap 0.8, как правило используемый для ограничения отдельных приложений непривилегированных пользователей. На практике Bubblewrap применяется проектом Flatpak в качестве прослойки для изоляции запускаемых из пакетов приложений. Код проекта написан на языке Си и распространяется под лицензией LGPLv2+...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=58721
флатпаки и прочее явно не панацея от поломанных зависимостей
Случай, когда во flatpak зависимости ломаются приведешь? Или ты так, набросить?
Когда тебе надо откатится на старую версию софта во флатпаке. Для это надо зайти в лог коммитов и откатится на один из коммитов, но выясняется что он хранит только последние 10 коммитов. А если ты даже знаешь номер старого коммита то ты откатится на него не можешь.
Но ведь это уже не про зависимости, а плохую особенность флатпака
Если ты от старой версии зависишь, то проблема сразу становится про зависимости)
Пользуйся Nix, там такой проблемы нет в принципе.
> Когда тебе надо откатится на старую версию софта во флатпаке.Это что, в этих "супер-пупер" пакетных менеджерах по прежнему нельзя установить параллельно разные версии одного и того же софта? Мда, а дифирамбов-то этим блоатваре сколько было...
>Случай, когда во flatpak зависимости ломаются приведешь?А этот твой flatpak он что, заговорённый?
Так-то там тоже зависимости есть. И от принципа «всё своё ношу с собой» разрабы flatpak собираются отказываться уж не первый год как: оказывается, если таких пакетов в системе не два — три, то вопрос экономии дискового пространства становится весьма актуальным. Одно дело, когда две или три программулины весом до ста метров занимают по полтора — два гига (а то и больше) каждая, другое дело, когда таких программулин надо установить штук 30, да ещё предусмотреть место для бэкапа корня. И вот чтобы с этим бороться, собираются применять (не начали ещё?) разделяемые среды. Ну т.е объединить все возможные минусы от смешения нескольких подходов, как нынче модно.
Вы про это?
> unbuffer flatpak list | rg -i platformFreedesktop Platform org.freedesktop.Platform 21.08.18
Freedesktop Platform org.freedesktop.Platform 22.08.8
Mesa org.freedesktop.Platform.GL.default 21.3.9
Mesa org.freedesktop.Platform.GL.default 22.3.5
Mesa (Extra) org.freedesktop.Platform.GL.default 22.3.5
Mesa git snapshot org.freedesktop.Platform.GL.mesa-git 23.0-branchpoint-2174-ge7c5a8b3f8f
ffmpeg-full org.freedesktop.Platform.ffmpeg-full
ffmpeg-full org.freedesktop.Platform.ffmpeg-full
openh264 org.freedesktop.Platform.openh264 2.1.0
openh264 org.freedesktop.Platform.openh264 2.1.0
openh264 org.freedesktop.Platform.openh264 2.1.0
GNOME Application Platform version 42 org.gnome.Platform
GNOME Application Platform version 43 org.gnome.Platform
KDE Application Platform org.kde.Platform
KDE Application Platform org.kde.PlatformДовольно удобно: например, если есть баг в работе приложения с платформой/драйвером, я спокойно могу сказать использовать другую, ничего не меняя в приложении или системе
flatpak run --runtime-version=21.08 <app>— и всё будет работать (а остальные приложения продолжат работать со своей дефолтной платформой). Встроенными средствами дистрибутива мне бы пришлось откатывать, условно, драйвера для всей системы. Нормально без флатпака такое наверное могут только nix/guix.
Они же зависят только от общего для всех контейнеров bundle. И ABI не меняется какое-то время. Даже между дистрибутивами.Почем панацея и что тогда панацея?
А зависимости зло-))) Не вижу проблем в составе дистрибутива софта иметь все необходимые ему компоненты, место на винте, давно не актуальный параметр
>место на винте, давно не актуальный параметрЕсли оно терабайтами будет жраться, то это станет проблемой для очень и очень многих. а уж если речь не про десктоп, и не про сервер, то и подавно. Нужны бэкапы — добавляй к проблемам множитель.
К тому же, распухший / это не только сожранное место на дисках. Вот у меня раньше система была на разделе в 30 гигов. Раньше — это ещё лет 5 назад. Потом 50, теперь 100. И ладно место, но оно теперь побайтово копируется на nas и обратно в разы дольше. И да, три flatpak-а (которые содержат софт, раньше вполне себе устанавливающийся из системных реп) тут тоже сыграли роль, причём заметную. Прибавила ли моя система в функционале, удобстве и прочем в связи с ростом занимаемого пространства? Нет.
Расскажи, что там у тебя в системе на 30, 50, и даже 100 гигов? Прон заныканный от мамки в /var/lib/cache? Не считая полтора терабайта пользовательских данных, система с кучей внутренних сервисов и системой сборки занимает 14 гигов. Декстоп с GNOME — 8,5, включая снапшоты. Как ты на ста гигах поместиться не можешь — загадка века, но флатпак тут явно не при чём.
Думаю, что у него там 100 Гб логов насобиралось
>Расскажи, что там у тебя в системе на 30, 50, и даже 100 гигов?/usr 25+ Gib.
/var/lib/flatpak 5.5 GiB. 3 (три!) программулины. И почти 20% от прочего софта со всеми потрохами.
Весь остальной /var около 2 GiB.
/opt столько же.
Хомяк и тому подобное на других разделах.Итого занято чуть больше полтинника. Плюс задел под обновление.
Ты вообще в курсе, как обновление с релиза на релиз происходит? Не, так-то можно и /opt куда-нибудь перемонтировать, и system-upgrade, и flatpak-помойку. Но это, знаешь ли, напрягает.
>Прон заныканный от мамки в /var/lib/cache?
Деточка, не надо проецировать на других. Если даже дяде оно и понадобится, у дяди быстрый интернет. И даже если пожилая мама приедет к дяде в гости, она один шут не сможет найти ни фильмы твоего любимого жанра, ни что-либо ещё, где бы это что-то ни находилось. Дядя ей инструкции по очистке смс с кнопочного телефона регулярно пишет и телепрограммы настраивает.
>система с кучей внутренних сервисов и системой сборки занимает 14 гигов
Твоя система, дитя. Твоя.
Ах да, ещё /share увесистый. Ну и swapfile динамический может разжиреть.
Для сравнения другой пример.$ flatpak list --app |wc -l
124$ flatpak list --runtime |wc -l
48$ btrfs filesystem du -s /var/lib/flatpak
Total Exclusive Set shared Filename
22.34GiB 22.03GiB 257.19MiB /var/lib/flatpakЗа редкими исключениями, это почти все графическое прикладное ПО в системе, в том числе игры (Mindustry, Wesnoth и что-то ещё). Плюс, аудио- и видеокодеки, Wine и Proton-GE Runtime, SDK для языков программирования (LLVM, MinGW, Vala, Java, Dotnet, Rust, Golang).
Что в сравнении с твоим примером:
Количество программ ~ x40
Потребление места на диске ~ x4Выводы делай сам. Меня устраивает.
--
Меня в Flathub'е куда больше беспокоит слабый контроль за тем кто, когда и как пакетирует. Нередко ПО обновляется с запозданиями, в сравнении с роллинг-дистрибутивами, а иногда даже на полгода-год. Часто пакеты пакетируют с устаревшими зависимостями или долго не обновляют рантайм, даже когда нет проблем с API/ABI, зато есть известные уязвимости в старом. Некоторые официальные поставщики ПО не вызывают доверия. Исполняемые файлы хранятся в ФС с привилегиями пользователя. Доступ программам в песочнице выдается довольно широко. Вкупе, озвученные проблемы создают дополнительные риски безопасности системы.
Не видь. Это не отменяет твоей слепоты, а не правоты.
Проблема не только в занимаемом месте на накопителе.Ещё - в потреблении оперативной памяти, растущем с каждой запущенной программой, слинкованной со своими "неповторимыми" версиями общих зависимостей.
А самая большая проблема кроется в актуальности (обнаруженных уязвимостей для) зависимостей, исключить которую можно только своевременным, централизованным их обновлением.
годная вещь
поясните я не совсем понял зачем оно
Чтобы разработчику голову не забивать наборами библиотек дистрибутивов, которых миллион. Если работает флатпак значит 99.9% шанс, что будет работать содержимое flathub
Ну и приятные плюшки для безопасности и стабильности за счет изоляции от системы
Ты имел в виду через жп работает и не возможно пользоваться? Большинство пользователей после этого удаляют линукс.
В оффтопе и маке софт итак распространяется правильно им прослойки и контейнеры не нужны.
Насильно-"правильно". Просто отрубают то что не подходит - вот и всё.
Либо ставишь потом то что правильно, либо - сидишь без ПО
А ведь тот же новый XCode у яблока - это порядка 7 Гб установочника, который, не дай Боги, хотя бы единственную проблему словит в ходе скачивания - тогда всё заново
Но вы же всегда можете скачать исходный код и скомпилировать. Исходный код свободного ПО (и даже не совсем свободного) у вас никто не отберет.
Более того можете взять LFS и сидеть компилировать до посинения.
Мы можем. Но выше написали про яблочников.
Яблочники сделали правильно и хорошо. LFS и Линукс сделали всё неправильно и плохо. Поэтому линуксом на обычных компах никто не пользуется из нормальных людей.
> Но вы же всегда можете скачать исходный код и скомпилировать. Исходный код
> свободного ПО (и даже не совсем свободного) у вас никто не
> отберет.
> Более того можете взять LFS и сидеть компилировать до посинения.Как бы да, но у XCode нет свободного ПО
Слава Богам, что есть Опенкор, позволяющий ставить яблочную ОСь даже на ноутбучные амд ( харам !! ) . Но свежая энвидиа всё равно не поддерживается - только амд радеон
Т.е. XCode должен зависеть от 6 гигов системных библиотек и весить 1 гиг? Но зачем?
> Т.е. XCode должен зависеть от 6 гигов системных библиотек и весить 1
> гиг? Но зачем?Ууу, пацан, ты ещё многого не знаешь...
Вот обновляются, например, шланг или гнутый или, даже, вижуал студио для соответствия с новыми веяниями языка...
На винде или линуксе ты просто скачаешь новый пакет/приложение/сборку - и кайфуешьИ только на яблоке, если обновления старше чем 1год относительно текущей оси... тебе, чтобы возрадоваться новым плюшкам компилятора, прежде надо обновить ОСь 10Гб ), после - XCode( ~10 Гб ) - и это при условии что железо поддерживаемо а тырнет - абсолютно стабилен, ведь яблоко при любом чихе начинает загрузку с нуля ! )
И это без учёта того, что яблоко ежегодно выкидывает часть железа как неподдерживаемое. Слава Богам что есть опенкор и на интелловских процах( с амд-шными тонны гемора ) начиная от коффе-лейк ещё можно поставить яблочную ОСь с нативной поддержкой и проца и интегрированной графики( только чутка подпатчить. С Энвидией вообще никакие пляски не спасут ибо выпилена подчистую. Но там хотя бы аймак 19,1 )
Так всё что ты описал это правильно и надёжно. Так и должно быть. Или что правильно это для свежатинки сделать ./configure; make; make install а потом несколько дней разбирать лапшу зависимостей по одной? А потом разгребать куда же это всё установилось размазавшись по системе тонким слоем? Или правильно ныть что мейнтенеры не соизволили собрать свежатинку? Или вообще ждать ебилдов?Какая вообще проблема взять да и обновится на маке? Типа ты потеряешь несколько часов своего итак ничего не делания? Кеши хранить ты что скопидом? А если кеши повредится или его специально заменят? Денег на трафик и железо нет? А зачем эплу поддерживать убожество которое ухудшает пользовательский опыт? Чтобы ты бедняк смог сэкономить? Зачем эплу нужно чтобы ты экономил? Весь твой коммент с точки зрения нормального человека бред. Эпл всё делает правильно. А ты делаешь всё неправильно.
Неправильно, когда какое-нибудь обновление свифта с 5.2 на 5.4 подразумевает обновление XCode, которое подразумевает обновление ОСи. Без каких-либо вариантов выбора. Неправильно, когда даже минорное обновление ЯП может требовать полную переустановку IDE и вообще всей ОС. Ещё и со стартом загрузки сначала на любой чих ведь они до сих пор не поддерживают докачку.Яблоко вертело и плевало на пользовательский опыт и прочую ерунду
И даже если всё пройдёт нормально( что совсем не обязательно ) - нет никаких гарантий, что иные данные и ПО после обновления не отвалятся( и не факт что они ещё поддерживаются )В районе Каталины, например, яблоко просто взяло - и запретило вообще всё 32-битное, включая вайн и старые штуки через него запускаемые. Вот просто нет и всё.
Тут с некоторой тоской вспоминается вижуал студио, который не требует переустановки ОС на каждое обновление C++ или C#
Вообще-то, никто не требует кроме яблока и икс-кодаА уж обновление я-оси на я-фоне... там перед каждым лучше полную копию сделать и загрузить образ новой прошивки, иначе хорошие шансы получить кирпич или, в лучшем случае, рабочее но полностью сброшенное устройство
>В оффтопе и маке софт итак распространяется правильно им прослойки и контейнеры не нужны.В гробу я видал такую «правильность».
Bubblewrap != flatpak
Это всегда была забота мэнтейнера пакета в конкретном дистрибутиве.
> зачем ононикто точно не знает
Запускать вложенный баблврап из уже созданного баблврап-окружения научились?
Там это, вложенный unshare конечно работает, но совсем не так, как хотелось бы пользователю. Поэтому не понятно, чего ты вообще хочешь от него.
Nixos-specific
В NixOS вообще нет изоляции приложений. А вот используй они bwrap (--bind) для создания окружения вместо кучи симлинок, была бы и изоляция процессов, и порядок в ФС, и патчей сборки стало бы меньше. Но не шмогла.
>Для выполнения привилегированных операций по настройке контейнера Bubblewrap запускается с правами root (исполняемый файл c suid-флагом) с последующим сбросом привилегий после завершения инициализации контейнера.И чем это лучше, чем firejail?
firejail - это блоатварь, а как и в любой другой блоатвари, в firejail неоднократно находили уязвимости. Да такие, что без fairjail было бы безопаснее, чем с ним. Такой вот парадокс. Ну а сабж тем временем дает истинно минимальный функционал, основанный исключительно на неймспейсах.
А уязвимости эти эксплуатирются удалено али как?
>в firejail неоднократно находили уязвимостиСрочно на раст переписать надо, не иначе!
думаешь загасить одни уязвимости другими?!
> в firejail неоднократно находили уязвимости.Уязвимости в bubblewrap https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=bubblewrap - это, конечно, другое.
способов атаковать firejail на порядки больше, чем сабж. Просто потому, что сабж -- это просто прослойка над linux namespaces (читай: unshare(2) заэкспортировали в виде шелл-скриптуемого бинаря). firejail тем временем пытается быть решением под ключ, и его кривая реализация распространяется много дальше неймспейсов. Поэтому что в прошлом, что в будущем - firejail всегда будет давать заметно большее кол-во CVE.
> способов атаковать firejail на порядки больше, чем сабж. Просто потому, что сабж
> -- это просто прослойка над linux namespaces (читай: unshare(2) заэкспортировали в
> виде шелл-скриптуемого бинаря). firejail тем временем пытается быть решением под ключ,
> и его кривая реализация распространяется много дальше неймспейсов. Поэтому что в
> прошлом, что в будущем - firejail всегда будет давать заметно большее
> кол-во CVE.firejail решает задачу изоляции для любого бинарника, это может быть консольная утилита или графическое приложение, не важно как я его установил себе: пакетом или просто скачал бинарь. К тому же у firejail поддерживает профили для большинства приложений из коробки. Как подобного добиться с bubblewrap? Использовать flatpack? Но это навязывание способа установки софта и соответствующей инфраструктуры откуда эти пакеты брать.
> И чем это лучше, чем firejail?Это проблема курицы и яйца. Чтобы настроить контейнер нужны привилегии. Либо suid, либо как в докере.
В твоей цитате из новости лишь малая часть правды.Ядро собранное с включенным CONFIG_USER_NS_UNPRIVILEGED (например, штатные ядра в Арче, кроме linux-hardened) позволяет поставлять bwrap без suid бита (например, как в штатном пакете bubblewrap в Арче) и, следовательно, запускать с привилегиями обычного пользователя. Firejail стартует только под рутом (SUID) или придётся выкинуть из него все фичи, вроде тонкой настройки сети, без которых он превратится в перегруженную версию bwrap'а.
Network namespaces будут?
Они там изначально. Дополнительные настройки реализуются в другом месте, см. passt(1).
> Они там изначально. Дополнительные настройки реализуются в другом месте, см. passt(1).Ну вот чуть влево вправо все реализуется отдельно. Зачем тогда сравнение с firejail?
Это называется Unix-way. Полагаю, сравнение демонстрирует одно из достоинств Bubblewrap - модульность.
> Это называется Unix-way. Полагаю, сравнение демонстрирует одно из достоинств Bubblewrap
> - модульность.Суть в том, что по функционалу сам по себе он умеет сильно меньше, чем firejail. Этот как сравнивать grep с vim и говорить, что в первом меньше уязвимостей.