Linux точка монтирования что это
Глубокое погружение в Linux namespaces, часть 3
Mount namespaces изолируют ресурсы файловых систем. Это по большей части включает всё, что имеет отношение к файлам в системе. Среди охватываемых ресурсов есть файл, содержащий список точек монтирования, которые видны процессу, и, как мы намекали во вступительном посте, изолирование может обеспечить такое поведение, что изменение списка (или любого другого файла) в пределах некоторого mount namespace инстанса M не будет влиять на этот список в другом инстансе (так что только процессы в M увидят изменения)
Точки монтирования
Давайте начнём с запуска терминала в его собственном mount namespace:
Строго говоря, нам не понадобится доступ уровня суперпользователя для работы с новыми пространствами имён mount, поскольку мы добавим процедуры настройки user namespace из предыдущего поста. В результате в этом посте мы предполагаем, что только команды unshare в терминале выполняются от суперпользователя. Для isolate в таком предположении необходимости нет.
Теперь, с одной стороны, поскольку мы пытаемся позаботиться о безопасности, мы могли бы просто сказать нах* всё и сделать в isolate полную очистку содержимого этого списка перед выполнение команды. Но это сделает запуск команды бесполезным, поскольку каждая программа, по крайней мере, зависит от ресурсов, вроде файлов операционной системы, которые, в свою очередь, обеспеченны какой-то файловой системой. С другой стороны, мы могли бы просто выполнить команду как есть, расшарив на неё те же файловые системы, что содержат необходимые системные файлы. Но это сводит на нет цель этого производимого нами дальше изолирования.
Лучшее решение — предоставить программе собственную копию зависимостей и системных файлов, которые требуются для запуска целиком в «песочнице», чтобы она могла вносить в них какие-либо изменения, не влияя на другие программы в системе. По лучшему сценарию мы можем поместить эти файлы в файловую систему и смонтировать её как корневую файловую систему (в корневой каталог / ) до выполнения ничего не подозревающей программы. Идея заключается в том, что поскольку всё, что доступно процессу, должно достигаться через корневую файловую систему, и поскольку мы будем точно знать, какие файлы мы туда помещаем для командного процесса, мы будем спокойны, зная, что он должным образом изолирован от остальной системы.
Хорошо, в теории это звучит хорошо и для реализации этого мы сделаем следующее:
Корневые файловые системы
Pivot root
Давайте посмотрим на это в действии. В нашем новом mount namespace мы начинаем с создания файловой системы из наших файлов alpine:
Затем мы делаем pivot root:
При этом мы можем запускать любую команду в нашем шелле, и она будут работать с использованием нашей специфичной корневой файловой системы alpine, пребывая в неведении об инструментарии, что привел к её запуску. И наши драгоценные файлы в старой файловой системе находятся вне пределов досягаемости.
Реализация
Нам нужно вызвать эту функцию из нашего кода и это должно быть выполнено нашим командным процессом в cmd_exec (поскольку он работает в новом mount namespace) до фактического начала выполнения команды.
Давайте попробуем это:
PID Namespaces
Мы уже несколько раз упоминали каталог /proc в этой серии постов, и если вы были знакомы с ним, то, вероятно, не будете удивлены тому, что вывод ps оказался пустым, поскольку мы видели ранее, что каталог был пуст в этом mount namespace (когда мы получили его из корневой файловой системы alpine).
PID namespace изолирует ID процессов в системе. Одним из следствий тут является то, что выполняющиеся в разных пространствах имён PID процессы могут иметь одинаковые идентификаторы процесса, не конфликтуя друг с другом. Допусти, мы изолируем это пространство имён потому, что мы хотим обеспечить как можно большую изолированность нашей запущенной команде. Однако более интересная причина, по которой мы рассматриваем это здесь, заключается в том, что монтирование файловой системы proc требует привилегий пользователя root, а текущий PID namespace принадлежит пользователю root, где у нас нет достаточных привилегий (если вы помните из предыдущего поста, root у командного процесса на самом деле не root). Итак, мы должны работать в PID namespace, владельцем которого является пользователь пространства имён, которое считает наш командный процесс запущенным от root.
Мы можем создать новый PID namespace, передав CLONE_NEWPID для clone :
Мы можем воспользоваться isolate для очередного запуска:
Это выглядит намного лучше! Шелл считает себя единственным процессом, запущенным в системе и работающем с PID 1(поскольку это был первый процесс, запущенный в этом новом PID namespace)