Home Arch Install — установка пакетов без привилегий администратора

Процесс установки софта разделяется на несколько этапов:
  - Получение привелегий root;
  - Обращение к пакетному менеджеру.
Вносить изменения в работу системы может только администратор. Соответственно, пакетный менеджер, имея только лишь права user, не выполнит ни единого действия, способного хоть как-то изменить систему. И это нормально. Такой подход используется для установки и обновления пакетов, которые остаются в системе до тех пор, пока пакетный менеджер не получит инструкцию по их устранению.

Что если права администратора отсутствуют, но есть необходимо установить какую-либо гипотетическую программу? Либо привелегии имеются, но корневой раздел (внезапно) примонтирован с опцией readonly, — иначе говоря, установка софта в систему не соответствует требуемой семантике решения (нужно просто установить, просто запустить и просто удалить). Один из вариантов исхода — скачать программу и запустить её, — возможно, повезёт и она действительно запустится.

Более интересен второй вариант, когда она не запустится. Это будет логичным поведением, если в системе не будут установленны требуемые зависимости. Понятно, что необходимо:
  - Первое — получить эти зависимости (тем же путём, что и желаемую программу);
  - Второе — как-то запустить всё это.

Для корректного запуска необходимо изолированное окружение. Желательно, на основе текущего состояния системы (в противном случае придётся получить вообще все зависимости в рекурсивном порядке, что ужасно).

Home Arch InstallДумаю, сначала стоит рассказать о простом пути — это, в общем-то, и есть тема статьи. Под скриншотом — решение для Arch-based (работа скрипта сосредоточена на пакетном менеджере pacman) систем, интересующихся решением прошу перейти к следующему заголовку и далее.
Home Arch Install (далее hai) — скрипт, который позволяет установить пакет, не требуя привелегий администратора. Располагается он здесь и почти не требует установки. Потому что она сводится к клонированию репозитория и заданию специального алиаса к скрипту:
Далее редактируем rc-файл шелла (~/.bashrc, ~/.zshrc, ~/.tcshrc, etc...):
И устанавливаем в систему некоторые зависимости, которые использует hai (это и только это действие выполняется от root):
Всё. Делаем exec "$SHELL", теперь можно приступить к изучению программы. Синтаксис её использования прост:
hai [--upgrade] <packages> -- <command>
Если <command> не задан, то на его место копируется значение с <packages> (первое, если их несколько). Ключ --upgrade используется для обновления баз данных пакетов (при первом запуске они скачивается независимо от этого ключа), и самих пакетов при их использовании (т. е. лениво, когда надо — тогда и обновимся).

Попробуем что-нибудь установить. Например, есть необходимость в fish (предположим, его нет в текущей системе) — красивый шелл, чаще всего используемый заменой bash-y. Следуя usage, выполняем команду:
...ждём несколько минут — скачиваются пакетные базы (и, собственно, сам пакет) — и оказываемся в окружении fish. Прежде установленные в системе пакеты более не скачиваются и рекурсивная цепочка подхватывания зависимостей на них обрывается.

Как работает hai
Hai создаёт специальное окружение в ~/.hai:
  - ~/.hai/sync: базы данных пакетов. По умолчанию — core, extra и community;
  - ~/.hai/cache: здесь находятся все скачанные пакеты;
  - ~/.hai/unions: ключевая директория. Здесь находятся те файловые системы, в которые попадает пользователь при установке какого-либо софта.

Hai конструирует файловую систему unionfs(8) и монтирует в ~/.hai/unions/<random-string>. Она предназначена для каскадно-объёдинённого монтирования (union mount) других файловых систем. Таким образом можно сказать, что hai создаёт ещё одну точку монтирования для root и мерджит в неё файлы указанных пакетов.

Далее — fakechroot(1) в новую файловую систему.

Если рассмотреть установку пакета чуть детальнее, то работа скрипта сводится к:
  - Запросу баз данных для получения информации о пакетах;
  - Скачиванию пакета;
  - Созданию UnionFS;
  - Чруту в UnionFS;
  - Отмонтированию UnionFS.

Безопасно ли это?Ну да. Во-первых, права всё те же — юзер, причём без возможности получения прав администратора (потому что -o nosuid по дефолту). Во-вторых, пакеты вообще не устанавливаются; файлы пакетов используются для формирования unionfs, не более того. В-третьих, — изолированное окружение.

Действительно ли специфично для pacman?Немного. pacman используется, но редко; сам по себе принцип работы завязан не на нём: hai самостоятельно скачивает тарболлы (базы данных, ога) и пакеты, затем используя файлы пакетов для конструирования UnionFS, — на самом деле, никакой установки не происходит. При желании каждый может форкнуть репо и подправить скрипт для работы с собственным пакетным менеджером. GitHub: barthalion/hai.