LINUX.ORG.RU

Как лучше реализовать изолированную установку программ?

 


0

2

Собираюсь создать пакетный менеджер на языке shell-scripting, возник вопрос изолирования процесса установки файлов в систему после компиляции.

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

Если использовать chroot или отдельного пользователя, после каждого пакета надо будет делать копию предыдущего состояния корня... В конце концов туда-сюда копировать гигабайты корня для каждого отдельного пакета — будет утомительный процесс. Плюс, наверняка, некоторые одни и те же файлы могут быть одновременно частью нескольких пакетов. Как отследить это, если файл уже существует?

Про LD_PRELOAD читал, что в некоторых ситуациях оно не всегда может отследить всё (в LFS, вроде бы, пишут что не может отслеживать статически скомпилированные программы), что его можно обмануть подменой переменных или с помощью каких-то системных вызовов.

Есть мысль, для каждого пакета парсить строки из makefile'а из секции install. Вопрос только, вдруг там могут быть какие-то услоавия if ..,;then ...;else ...;fi... Т.е. придётся для каждого пакета вручную создавать сценарий установки, а хотелось бы автоматизированно. Или там не бывает условий?

Как вообще всё это лучше организовать? Есть готовые решения?

★★★★★

а разве после установки в систему не привносится угроза?

или у тебя песочница перманентная? и там в песочнице установленный софт живет?

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

например скрипт который умеет только распаковать и скопировать, но проблема в том, что при распаковке может быть переполнение буфера...

anonymous ()

Есть идея держать копию корня в отдельном каталоге, но с другим юзером, и в чруте устанавливать туда программы, и на основании разницы в файлах, делать лог установленных файлов.
Но есть несколько вопросов:
опять же, как отслеживать файлы, которые уже были, как часть другого пакета, которых если б не было, последний установленный пакет создал бы?

правильно ли устанавливать ПО не рутом?

может ли юзер из чрут окружения повлиять на корневую систему (через /dev, /sys, /proc, или как-то ещё...) ? Может ли юзер из чрут окружения выбраться с помощью chroot, mount, как-то ещё? Как это не допустить?

teod0r ★★★★★ ()

в линуксе куча технологий для sandbox-инга

anonymous ()
Ответ на: комментарий от anonymous

какие? vm?
а ведь это идея! мой пред-предыдущий комментарий + vm

teod0r ★★★★★ ()
Последнее исправление: teod0r (всего исправлений: 1)
Ответ на: комментарий от anonymous

а разве после установки в систему не привносится угроза?

при чём здесь угроза? речь про пакетный менеджер

teod0r ★★★★★ ()
Ответ на: комментарий от anonymous

какая виртуализация для этого больше всего подойдёт? чтоб можно было полностью всё управлять скриптом, запущенным хост-системой

teod0r ★★★★★ ()

Собираюсь создать пакетный менеджер на языке shell-scripting, возник вопрос изолирования процесса установки файлов в систему после компиляции.

Какая связь между компиляцией и пакетным менеджером?

Наверное тебе нужен fakeroot. Ты бы описал задачу, а то пока это выглядит как велосипед велосипедов

disarmer ★★★ ()
Ответ на: комментарий от teod0r

Это академический проект? Иначе нет смысла, есть abs/aur с тысячами пакетов и готовой системой сборки. На входе простенький файл с описанием - на выходе готовый пакет.

disarmer ★★★ ()
Ответ на: комментарий от disarmer

простенький файл с описанием

скорее махровый bash скрипт

anonymous ()
Ответ на: комментарий от teod0r

а вот тебе идея позаниматься школьными вечерами — раз уж для каждого пакета всё равно пилится скрипт сборки, запускающий апстримную систему сборки, то выкинуть последнюю и запускать конпилер прямо из пакетного менеджера, игнорируя autotools/мэйкфайлы. из плюсов будет значительное улучшение параллельности сборки

anonymous ()
Ответ на: комментарий от anonymous

ну и секурнее, тк не запускается посторонний код

anonymous ()
Ответ на: комментарий от anonymous

игнорируя autotools/мэйкфайлы

а разве создателю тарбола не виднее, что и как собирать? или ты предлагаешь прочитывать все исходники перед компиляцией?

teod0r ★★★★★ ()
Ответ на: комментарий от teod0r

конечно, а какая же иначе security лол

на самом деле никаких особых дел скрипты сборки не делают, в 99% случаев там просто $compilername $sourcefile а потом все обьектники линкуются в одну либу/бинарь. нужно просто определить все дефайны — что уже делается в виде в виде юз флагов. из особых фокусов можно вспомнить только версионирование символов линкером в glibc и fuse

anonymous ()

Каким образом это лучше осуществить?

Кури sys-apps/sandbox в Gentoo. Можно еще дунуть в sys-apps/proot. Я имею ввиду в исходники, если ты озадачился написать пакетный менеджер сам и не привлекать внешние утилиты.

Pinkbyte ★★★★★ ()
Последнее исправление: Pinkbyte (всего исправлений: 1)
Ответ на: комментарий от disarmer

Транслятор из PKGBUILD в декларативный формат был бы интересен. Понятно, что он будет работать далеко не на всём, но многие пакеты написаны по одному шаблону и вытащить их из ABS/AUR — вполне достаточно для немаленького репозитория.

x3al ★★★★★ ()
Ответ на: комментарий от x3al

А зачем нужен декларативный формат? Под все дистрибутивы всё равно не получится собирать пакеты, под определённый что-то можно поправить по другому(пути директорий)

disarmer ★★★ ()

Попробуй unionfs использовать. Ориджинал-корень в ro-ветвь, rw-ветвью пусть будет изначально пустая директорией. После установки посмотришь, какие там файлы появились.

I hope you got it.

kike ()
Ответ на: комментарий от teod0r

может ли юзер из чрут окружения повлиять на корневую систему (через /dev, /sys, /proc, или как-то ещё...) ? Может ли юзер из чрут окружения выбраться с помощью chroot, mount, как-то ещё? Как это не допустить?

Ты уж определись, тебе нужно просто отследить, какие файлы ставятся и софту ты, в принципе, доверяешь. Или тебе нужно создать песочницу для недоверенного, потенциально небезопасного софта.

kike ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.