ТЗ

Общие сведения

Необходимо реализовать "псевдо файловую систему" (далее ПФС), которая будет обеспечивать поддержку легковесных контейнеров и решать следующие три задачи:

  1. Персонализация части файлов в /proc для обычных пользователей (или групп пользователей),
  2. Персонализация файлов-устройств терминалов в /dev/pts для обычных пользователей (или групп пользователей),
  3. Проецирование некоторых частей файловой системы родительского контейнера, на части дочернего контейнера.

Под легковесным контейнером понимается chroot, в котором доступны части ФС родительского контейнера. В этом chroot выполняются все процессы пользователей этого контейнера. ПФС proc и devpts доступны в chroot только частично (подробнее в "персонализации"). Для каждого контейнера определяется перечень пользователей (перечень UID), все процессы которых выполняются в этом контейнере.

Под персонализацией понимается особое ограничение доступа, такое, что доступ предоставляется только к "собственной информации" (Вася знает все про себя, а Петя все про себя, но друг про друга они ничего не знают). Допустим в контейнер А назначены 3 пользователя П1, П2 и П3. Это означает что все процессы этих пользователей будут видеть (иметь информацию) о процессах пользователей П1, П2 и П3, но они не будут иметь информацию обо всем окружающем мире: процессах родительской системы и процессах пользователей всех "соседних" контейнеров.

Третья из выше описанных задач имеет наименьший приоритет и сейчас прекрасно реализуется комплексом mount'ов и symlink'ов. Как следствие — в первую очередь должны быть грамотно реализованы первые две задачи.

При реализации может быть как написан модуль к ядру, так и использоваться FUSE.

Основные требования к разрабатываемому ПО:

  • корректность и завершенность — должно удовлетворять ТЗ, и не содержать ошибок (приводящих к деперсонализации);
  • стабильность — должно быть стабильным, не вызывать сбоев и утечек памяти (планируется использование 24*365);
  • ресурсосбережение — контейнер, в особенности пустой, должен использовать минимальное количество системных ресурсов (планируется одновременный запуск от нескольких сотен до десятков тысяч контейнеров на одном компьютере, при этом в подавляющем большинстве контейнеров большую часть времени "ничего не будет выполняться", они будут пусты);
  • производительность — все операции, связанные с обращением к ПФС proc и devpts не должны быть более чем в 2 раза медленнее оригинальных, при обращении к остальным файлам (над которыми произведено проецирование) не должно теряться более нескольких процентов производительности.

Далее рассмотрены три описанных задачи отдельно с большими подробностями.

Далее везде, где не сказано обратное, под "/" понимается корень chroot, а не корень родительской системы (родительского контейнера).

Персонализация proc

В /proc содержатся:

  • директории, описывающие процессы,
  • другие файлы и директории, предоставляющие общесистемную информацию.

Информация процессов

Допустим, что следующая команда осуществит монтирование "proc с персонализацией": 

# mount -t jailproc proc /proc -o users=1001,1002,1003

Существует 3 случая:

  1. Доступ к /proc одного из пользователей.
  2. Доступ к /proc пользователя root.
  3. Доступ к /proc стороннего пользователя (ситуация маловероятна, но возможна).

В первом случае доступ предоставляется к процессам (к информации о процессах), принадлежащим пользователям 1001, 1002, 1003.

Во втором случае доступ предоставляется ко всем процессам, без ограничений.

В третьем случае не предоставляется информации ни о каких процессах.

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

  1. Отображаются только: cmdline, environ, limits, mounts, stat, statm, status.
  2. Содержимое файла mounts генерируется по отдельному алгоритму. Основные особенности:
    1. в нем указывается /proc, /dev и /root.
    2. размер /root указывается не на основании реально имеющегося места на диске, а на основании использования дисковой квоты контейнера (продумать подробнее).
  3. ...

Во втором случае предоставляется доступ ко всем файлам, их содержимое не преобразуется.

Общесистемная информация

На подобии файлов с информацией о конкретном процессе файлы с информацией о системе в целом показываются по следующему алгоритму (будет расширяться):

  1. Отображаемые файлы: mounts, cpuinfo, crypto, devices, execdomains, filesystems, interrupts, loadavg, locks, meminfo, modules, stat, swaps, uptime, version, self.
  2. Содержимое mounts генерируется по отдельному алгоритму (смотреть выше).
  3. self — это symlink на директорию с информацией о текущем процессе.
  4. ...

Персонализация devpts

Допустим, что следующая команда осуществит монтирование "depvpts с персонализацией": 

# mount -t jaildevpts devpts /dev/pts -o users=1001,1002,1003

Как описано выше — существует 3 случая (пользователь контейнера, пользователь root, сторонний пользователь).

В первом случае доступ предоставляется только к файлам принадлежащим пользователям контейнера.

Во втором случае — доступ предоставляется к файлам, принадлежащим пользователям контейнера и к файлам принадлежащим пользователю root.

Проецирование частей родительской системы

...

TODO по ТЗ

  1. Дописать алгоритм фильтрации обращений к информации о процессе.
  2. Дописать алгоритм фильтрации обращений к информации о системе в целом.
  3. Продумать что делать с "дисковыми квотами" (фактически — ответ на вопрос "а что показывать по df").
  4. Расписать подробности "проецирования"