Задачка для сисадминов. Программы и библиотеки под chroot’ом

[dil]

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

Соответственно, все нужные программы и разделяемые библиотеки к ним должны лежать в доступных пользователю поддиректориях, а благодаря chroot’у все они могут располагаться только внутри его домашней директории. Пользователей, сильно больше одного, и делать каждому по отдельной копии всех программ и библиотек накладно будет. Хочется обойтись одним физическим экземпляром на всех.

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

И что делать?

Вопрос на пятёрку: а если это не линукс?

Оригинал этой записи в личном блоге.
Любые материалы из этого блога запрещается использовать на сайте livejournal.ru в любой форме и любом объёме.

Comments

[alexkuklin]

mount --bind?

[dil]

Правильно. Переходим ко второму вопросу: а если это не линукс?

[alexkuklin]

"вынимает вилку из уха, втыкает в глаз и говорит - иди к окулисту, он еще принимает" (ц)

[mcjabberwock]

это - пять!!
(есличё, nullfs во FreeBSD есть, сам видел)

[salas.livejournal.com]

И не FreeBSD, потому что там действительно есть прямая замена. NFS, например. Но есть предчувствие, что решение alexkuklin гуманнее. :)

[blacklion.livejournal.com]

Система-то какая?
nullfs на фряхе.
ZFS клон файловой системы на фряхе и Солярке.
Про линукс уже ответили.
AIX? Windows?

[dil]

Да любая, на какой получится.
У меня линукс, поэтому для остальных систем задача чисто теоретическая.

Разве что кроме Windows. ssh там, конечно, есть, а chroot - вряд ли. Там же файловые системы не единое дерево образуют, в котором можно корень передвинуть пониже, а отдельные диски с буковками, которые непонятно как отображать.

[coctic]

По умолчанию - да, а так начиная с XP точно, а может и с 2000 можно смонтировать одну ФС внутрь другой, точно как в UNIX-like. Правда, я ни разу не видел, чтоб этим пользовались.

[dil]

Дополнительные файловые системы можно, но сама операционная система считает, что она живёт на диске с буквой (обычно C:), и от этого пока никуда не деться.

[coctic]

Это факт, да.

[lazylonelion.livejournal.com]

Я не особо хороший сисадмин, и, наверное, совсем слабый *nix-админ.
Но первое, что пришло мне в голову -- сделать отдельный read-only раздел под это дело -- под /bin, /lib и чо там ещё надо.
Причём этот раздел можно сделать виртуальным, вплоть до "держать в памяти" (хоть и не полностью уверен).

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

[dil]

Проблема в том, что отдельный раздел, если его заранее на заготовили, выделить будет сложновато. Можно, конечно, сделать его в файле, или в памяти, но гораздо удобнее просто сложить все нужные файлы в отдельную директорию и примонтировать её каждому пользователю.

Про многотыщ не знаю, не пробовал. Наверное, какие-то ограничения есть, но в моей ситуации количество пользователей исчисляется парой десятков. Хотя тут уже не важно, будет ли это директория или отдельная файловая система, монтировать придётся каждому пользователю индивидуально.

[lazylonelion.livejournal.com]

Конечно так удобнее.
А какие проблемы сделать раздел в файле?

[dil]

Проблем никаких, но это лишний уровень иерархии: файловая система в файловой системе. На скорости доступа сказывается отрицательно.