Разрешение символьной ссылки предохранителя под chroot - PullRequest
0 голосов
/ 18 января 2019

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

Я использую это с chroot-изображением Debian Wheezy из debboostrap. Идея состоит в том, чтобы отразить wheezy / в моей точке монтирования, затем процесс будет привязан к точке монтирования, и все действия будут записаны через мой предохранитель fs.

Похоже, ОС прекрасно справляется с разрешением пути с помощью chroot. То есть, если процесс chroot делает stat("/bin/ls"), из моего процесса fuse я вижу stat("wheezy/bin/ls").

Однако я не уверен, как обращаться с символическими ссылками. Например файл
wheezy/lib64/ld-linux-x86-64.so.2
указывает на
/lib/x86_64-linux-gnu/ld-2.13.so

Поэтому, когда я звоню stat("wheezy/lib64/ld-linux-x86-64.so.2"), это не будет работать, поскольку ОС попытается разыменовать символическую ссылку /lib/x86_64-linux-gnu/ld-2.13.so вместо правильного wheezy/lib/x86_64-linux-gnu/ld-2.13.so.

Это упрощенный пример, я не могу просто добавить wheezy/ ко всем путям, я также хочу поддерживать приложения, которые не выполняют или не выполняют многократную обработку.

Я могу придумать несколько менее идеальных способов сделать это, например, проверьте /proc/pid/root/, чтобы получить корень процесса в случае chroot, но тогда я должен всегда проверять, является ли файл символической ссылкой.

Есть ли лучший способ или общий способ решения этой проблемы файловыми системами на основе предохранителей?

1 Ответ

0 голосов
/ 23 января 2019

После обращения в список рассылки fuse-devel я получил следующий ответ:

If you are performing this stat(2) for GETATTR or LOOKUP, you should
be using lstat(2) instead. This will tell the kernel that you found a
symlink and it should keep managing path resolution correctly for you.

То есть используйте lstat(2) при обработке LOOKUP или GETATTR, используйте результаты lstat для заполнения структуры fuse. Оттуда ядро ​​автоматически обрабатывает разрешение имен (даже для символических ссылок и процессов, выполняющихся внутри chroot).

...