Читаем Linux API. Исчерпывающее руководство полностью

Данные системные вызовы не включены в стандарт SUSv3, но присутствуют в стандарте SUSv4. Чтобы сделать видимым объявление каждого из этих вызовов, следует указать значение не менее 700 для макроопределения _XOPEN_SOURCE (feature test macro, проверка функциональной возможности), прежде чем включать соответствующий заголовочный файл (то есть для функции open()). В качестве альтернативы можно указать в макроопределении _POSIX_C_SOURCE значение, которое больше или равно 200 809. (До выхода версии 2.10 библиотеки glibc было необходимо макроопределение _ATFILE_SOURCE, делающее видимым объявления этих системных вызовов.)

В ОС Solaris 9 и более поздних версиях присутствуют варианты некоторых интерфейсов, перечисленных в табл. 18.2, с немного отличающейся семантикой.

18.12. Изменение корневого каталога процесса: системный вызов chroot()

Каждый процесс обладает корневым каталогом — он представляет собой точку отсчета, от которой интерпретируются абсолютные имена путей (то есть начинающиеся с символа /). По умолчанию данным каталогом является реальный корневой каталог файловой системы. (Новый процесс наследует корневой каталог своего родителя.) Иногда бывает удобно, чтобы процесс изменил свой корневой каталог. Это может осуществить процесс с привилегией CAP_SYS_CHROOT с помощью системного вызова chroot().

Системный вызов chroot() изменяет корневой каталог процесса на каталог, указанный в аргументе pathname (который разыменовывается, если это символическая ссылка). Затем все абсолютные имена путей интерпретируются как начинающиеся с указанного местоположения в файловой системе. Иногда это называют заключением в клетку chroot, поскольку программа оказывается замкнутой внутри некоторой части файловой системы.

#define _BSD_SOURCE

#include

int chroot(const char *pathname);

Возвращает 0 при успешном завершении или –1 при ошибке

Стандарт SUSv2 содержал спецификацию системного вызова chroot() (с пометкой LEGACY («устарело»)), которая была изъята из стандарта SUSv3. Тем не менее системный вызов chroot() присутствует в большинстве реализаций UNIX.

Системный вызов chroot() задействуется командой chroot, позволяющей выполнять команды оболочки в клетке chroot.

Корневой каталог любого процесса можно найти, прочитав (readlink()) содержимое характерной для Linux символической ссылки /proc/PID/root.

Классическим примером использования системного вызова chroot() является программа ftp. В качестве меры безопасности при анонимном входе пользователя по протоколу FTP программа ftp применяет системный вызов chroot(), чтобы в качестве корневого каталога для нового процесса задать каталог, который специально зарезервирован для анонимных подключений. По завершении вызова chroot() пользователь ограничен поддеревом нового корневого каталога и поэтому не может «бродить» по всей файловой системе. (Это опирается на следующий факт: корневой каталог является собственным родителем; то есть путь /.. — ссылка на /, в связи с чем при изменении каталога на / с последующей попыткой выполнить команду cd.. пользователь остается в том же самом каталоге.)

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

В нормальном режиме нельзя выполнять произвольные программы внутри клетки chroot. Это вызвано тем, что большинство программ динамически связано с совместно используемыми библиотеками. Следовательно, мы должны либо ограничиться выполнением статически привязанных программ, либо реплицировать внутри клетки стандартный набор системных каталогов, содержащих совместно используемые библиотеки (такие, например, как /lib и /usr/lib) (в этом отношении может оказаться полезной функция связанного монтирования, описанная в подразделе 14.9.4).