Как убедиться, что sudo имеет setuid в переупакованных squashfs?
В дополнение к моему предыдущему комментарию к другому ответу , ядро содержит семь бинарных загрузчиков(ищите там файлы, начинающиеся с binfmt_, или читайте конкретныйbinfmt-Kconfig):
a.out(который в настоящее время приостановлено исполнение);- ЭЛЬФ;
- FDPIC ELF (на ARM, MMU -без SuperH и C6x );
em86(на Альфе );- плоские двоичные файлы (на системах без MMU -или ARM, или M68k );
- скрипты;
- всемогущий
binfmt_misc(см. также Какие форматы исполняемых файлов допускают файлы в каталоге /proc/sys/fs/binfmt _misc/?).
Это то, что определяет типы исполняемых файлов, которые может выполнять ядро. binfmt_miscв частности, позволяет ядру обрабатывать многие другие двоичные файлы (, по крайней мере, с точки зрения процесса, вызывающего одну из execфункций).
Тем не менее, это не вся история, так как также задействованы библиотека C и сами оболочки. POSIX теперь требует, чтобы функции execlpи execvpпри обнаружении исполняемого файла, который не может запустить ядро, пытались запустить его с помощью оболочки; см. обоснование здесь для деталей.
То, как все это взаимодействует, чтобы обеспечить поведение, которое вы видите, подробно описано в . Что именно происходит, когда я запускаю файл в своей оболочке? и Какой интерпретатор оболочки запускает сценарий без шебанга?
Предполагая, что вы используете unsquashfsдля распаковки файлов, вы получите набор принадлежащих вам файлов без битов setuid. Но вы можете вручную вернуть бит setuid для любых файлов, которые вы хотите (с помощьюchmod u+s); конечно, они будут настроены на ваш идентификатор. Но когда вы переупаковываете файлы с помощью mksquashfs, добавьте опцию -all-root, и все файлы в файловой системе будут принадлежать пользователю root, а не вам, и любой бит setuid будет сохранен.