Второй раз натыкаюсь на грабли от make-initrd (при работе installkernel): создаётся нерабочий initrd для устанавливаемого ядра. Ядро выпадает в kernel panic с сообщением о невозможности найти init. Поиск проблемы показал, что в initrd файл /init лежит, но это скрипт и в нём указана программа /bin/sh, которой почему-то не оказалось в initrd. Полученный нерабочий initrd (2Мб) и рабочий от программы mkinitrd (1Мб) могу выслать лично по почте. Здесь прикреплять не буду. Ошибка повторяется, если удалить initrd и создать его через installkernel при установленном make-initrd. $ rpm -qa|grep initrd make-initrd-devmapper-0.2.2-alt1 mkinitrd-busybox-1.3.2-alt1 make-initrd-0.2.2-alt1 mkinitrd-initramfs-3.0.10-alt1 mkinitrd-3.0.10-alt1 make-initrd-lvm-0.2.2-alt1 $ Файловая система: /dev/sda2 on / type xfs (rw) proc on /proc type proc (rw,noexec,nosuid,gid=19) sysfs on /sys type sysfs (rw) udevfs on /dev type tmpfs (rw) devpts on /dev/pts type devpts (rw) shmfs on /dev/shm type tmpfs (rw) /dev/sda1 on /boot type ext3 (ro,nosuid,nodev) /dev/sda5 on /usr type xfs (rw) /dev/sda6 on /var type xfs (rw) /dev/sda9 on /home type xfs (rw) jacktmp on /var/lib/jack/tmp type ramfs (rw) tmpfs on /tmp type tmpfs (rw,noexec,nosuid,size=10%) usbfs on /proc/bus/usb type usbfs (rw) none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
(В ответ на комментарий №0) > tmpfs on /tmp type tmpfs (rw,noexec,nosuid,size=10%) ^^^^^^ Я думаю, что это может быть из-за noexec.
(В ответ на комментарий №1) > (В ответ на комментарий №0) > > tmpfs on /tmp type tmpfs (rw,noexec,nosuid,size=10%) > ^^^^^^ > Я думаю, что это может быть из-за noexec. Точно, перемонтировал /tmp с exec и в initrd появилась ссылка /bin/sh->/bin/ash. А ведь никакой ошибки на экран не выдавалось с noexec. Теперь непонятно, считать ли это всё равно ошибкой или закрыть по причине local misconfiguration?
(В ответ на комментарий №2) > Точно, перемонтировал /tmp с exec и в initrd появилась ссылка > /bin/sh->/bin/ash. А ведь никакой ошибки на экран не выдавалось с noexec. > Теперь непонятно, считать ли это всё равно ошибкой или закрыть по причине local > misconfiguration? Давайте понизим Важность и оставим открытой ... я попробую придумать что тут можно сделать.
fakeroot может помочь?
(В ответ на комментарий №4) > fakeroot может помочь? Лёх, ты не понял. make-initrd и так уже рут (причём настоящий). В /tmp нельзя ничего исполнить.
(В ответ на комментарий №3) > Давайте понизим Важность и оставим открытой ... я попробую придумать что тут > можно сделать. Хорошо. Пусть хотя бы ошибку или предупреждение выдаёт, если где-то сборка initrd затыкается, а то сейчас в заблуждение вводит.
Собственно понятно: код "[ -x ./bin/$n ] || continue" не отработал из-за noexec и продиагностировать это не представляется возможным без анализа опций монтирования раздела, на котором мы создаём временный каталог. В качестве одного из путей решения это замена -x на -f, но это не правильно. Думаю перенести сборку в ${TMPDIR:-/tmp} и склоняюсь, что подобные случаи это local misconfiguration т.к. программы имеют право создавать и исполнять скрипты во временном каталоге (где же им ещё это делать?).
Сергей, вы таки попробуйте запустить make-initrd через fakeroot. Оно же ещё и за правами на файлы следит, а не только "кагбе рута" даёт.
Интересно, а почему mkinitrd не затыкается? Ведь задача этих программ - это сделать загрузочный образ для адра. Сам образ правильный создаётся (в том числе и права есть 755 на /bin/ash сотоварищи), а значит noexec в создании образа не помеха, единственно нет только симлинка /bin/sh -> /bin/ash. Хотя да, с noexec я переборщил. :-) У себя уже убрал.
Инсталлер, кстати, прописывает только nosuid для /tmp.
(В ответ на комментарий №10) > Инсталлер, кстати, прописывает только nosuid для /tmp. У меня система стоит с тех пор, когда ещё это не прописывалось. :-) И я сам строчку на основе /dev смастерил, не подумав про noexec.
(В ответ на комментарий №9) > Интересно, а почему mkinitrd не затыкается? Ведь задача этих программ - это > сделать загрузочный образ для адра. Сам образ правильный создаётся (в том числе > и права есть 755 на /bin/ash сотоварищи), а значит noexec в создании образа не > помеха, единственно нет только симлинка /bin/sh -> /bin/ash. Вы ошибаетесь. Вы не знаете как действует noexec. Вы можете скопировать выполняемый файл на такой раздел, но execute permission не будет действовать. Вы не сможете выполнить такой файл и не сможете проверить файл на _исполняемость_. mkinitrd только копировал файлы в директорию, не выполняя над ними других действий. make-initrd после копирования файлов ищет шелл (т.к. он допускает копирования любого шелла) и если нужно делает симлинк /bin/sh. Он выполняет "[ -x /somefile ]" который всегда false с noexec. Поэтому симлинк не создаётся.
(In reply to comment #7) > В качестве одного из путей решения это замена -x на -f, но это не правильно. Думаю, хотеть исполняемый /tmp более неправильно. А чуть ли не основной повод не делать его noexec из коробки -- mc. :-/ (In reply to comment #12) > make-initrd после копирования файлов ищет шелл (т.к. он допускает копирования > любого шелла) и если нужно делает симлинк /bin/sh. Он выполняет "[ -x /somefile > ]" который всегда false с noexec. Поэтому симлинк не создаётся. Может, find /tmp/sh -perm +0111?
(В ответ на комментарий №13) > Думаю, хотеть исполняемый /tmp более неправильно. А чуть ли не основной повод > не делать его noexec из коробки -- mc. :-/ С первым утверждением в корне не согласен. И аргумент я уже называл: программы имеют право генерировать скрипты и исполнять их. Твоё решение ведёт к тому, что они будут это делать в неожиданных местах вместо законного TMPDIR. Я не могу гарантировать, что в этом проекте не появятся скрипты выполняемые из workdir. > Может, find /tmp/sh -perm +0111? Вот только не нужно придумывать хаки для замены стандартной проверки. "test -x" это совершенно легальная и правильная проверка.
(In reply to comment #14) > (В ответ на комментарий №13) > > Думаю, хотеть исполняемый /tmp более неправильно. А чуть ли не основной повод > > не делать его noexec из коробки -- mc. :-/ > > С первым утверждением в корне не согласен. И аргумент я уже называл: программы > имеют право генерировать скрипты и исполнять их. Не все программы имеют такое право. И, обрати внимание, именно твоя программа оказалась в той системе первой, кому это право понадобилось. Зачем открывать этот ящик раньше времени? > Твоё решение ведёт к тому, что > они будут это делать в неожиданных местах вместо законного TMPDIR. В неожиданных местах они будут неожиданно получать EROFS или EACCES. Имей в виду наличие всяких ручек вроде selinux. > Я не могу гарантировать, что в этом проекте не появятся скрипты выполняемые из > workdir. Почему ты не можешь этого гарантировать? > > Может, find /tmp/sh -perm +0111? > > Вот только не нужно придумывать хаки для замены стандартной проверки. "test -x" > это совершенно легальная и правильная проверка. Это не хак, это возможный фикс, хотя мне больше нравится test -f. Проверка test -x нужна для выявления исполняемости, а в данном случае исполняемость никого не интересует, ибо никто не собирается исполнять тестируемые файлы в том контексте, в котором проводится тестирование. Да, и заодно пара пожеланий: - ссылка там пусть лучше будет относительной, а не абсолютной; - если в результате указанного в шебанге шелла не оказалось, хорошо бы вывести как минимум предупреждение.
(В ответ на комментарий №15) > Не все программы имеют такое право. И, обрати внимание, именно твоя программа > оказалась в той системе первой, кому это право понадобилось. Зачем открывать > этот ящик раньше времени? В каких каталогах можно создавать временные директории и гарантированно будет работать проверка на -x ? > > Твоё решение ведёт к тому, что > > они будут это делать в неожиданных местах вместо законного TMPDIR. > > В неожиданных местах они будут неожиданно получать EROFS или EACCES. От рута этих мест будет меньше чем у обычного пользователя. > Имей в виду наличие всяких ручек вроде selinux. У нас его нет, а в дистрибутивах там где он есть (fedora) initrd создаётся в TMPDIR (dracut). И, не поверите, они тоже там проверяют наличие шелла и тоже через -x. > Почему ты не можешь этого гарантировать? Потому что система модульная. > Это не хак, это возможный фикс, хотя мне больше нравится test -f. Дим, тебе не нужно объяснять разницу между -x и -f. > Проверка test -x нужна для выявления исполняемости, а в данном случае > исполняемость никого не интересует, ибо никто не собирается исполнять > тестируемые файлы в том контексте, в котором проводится тестирование. Разумеется это проверка важна. Я хочу быть уверенным, что в initrd я сделал симлинк на исполняемый файл, а не на обычный, потому что это ведёт к краху процесса загрузки.
(In reply to comment #16) > В каких каталогах можно создавать временные директории и гарантированно будет > работать проверка на -x ? Такую гарантию никто не даст. > > > Твоё решение ведёт к тому, что > > > они будут это делать в неожиданных местах вместо законного TMPDIR. > > > > В неожиданных местах они будут неожиданно получать EROFS или EACCES. > > От рута этих мест будет меньше чем у обычного пользователя. А почему только рут? Я хочу использовать make-initrd для создания рамдисков для контейнеров. Это ведь совершенно непривилегированная операция. > > Имей в виду наличие всяких ручек вроде selinux. > > У нас его нет, Это дело недолгого времени. > а в дистрибутивах там где он есть (fedora) initrd создаётся в > TMPDIR (dracut). И, не поверите, они тоже там проверяют наличие шелла и тоже > через -x. Ну и зря. В других дистрибутивах тоже делают ошибки и необоснованные допущения. > > Почему ты не можешь этого гарантировать? > > Потому что система модульная. На модули можно накладывать ограничения. > > Проверка test -x нужна для выявления исполняемости, а в данном случае > > исполняемость никого не интересует, ибо никто не собирается исполнять > > тестируемые файлы в том контексте, в котором проводится тестирование. > > Разумеется это проверка важна. Я хочу быть уверенным, что в initrd я сделал > симлинк на исполняемый файл, а не на обычный, потому что это ведёт к краху > процесса загрузки. Ты всё равно не можешь достверно установить будущую исполнимость файла в контексте рамдиска. Наличие атрибута u+x -- это необходимое, но не достаточное условие исполнимости. Проверка test -x не даёт гарантии исполнимости даже в нативном контексте, не говоря уже о чужом контексте. Вот простой пример: $ echo '#!/missing' > sample && chmod 700 sample && test -x sample && ./sample -bash: ./sample: /missing: bad interpreter: No such file or directory $ env -i strace -eexecve ./sample execve("./sample", ["./sample"], [/* 0 vars */]) = -1 ENOENT (No such file or directory) strace: exec: No such file or directory Ты ведь знаешь, чем отличается проверка access(X_OK) от stat() с последующим тестом на S_IXUSR|S_IXGRP|S_IXOTH. Какая тебе польза от этой разницы? Вот код, о котором идёт речь: for n in bash dash mksh ash; do [ -x ./bin/$n ] || continue ln -s /bin/$n ./bin/sh break done Возникают дополнительные вопросы: - если ./bin/sh уже существует, то будет exit 1; - если любой из вышеперечисленных файлов существует и является абсолютной ссылкой, то проверка test -x может пройти, в то время как файл, на который указывает ссылка, в образ не попадёт; - как был получен этот список шеллов? - зачем вообще нужен этот ./bin/sh?
(В ответ на комментарий №17) > Такую гарантию никто не даст. Значит использование TMPDIR правомерно т.к. оно предназначено для хранения временных файлов. Дополнительные ограничения на совести администратора. > А почему только рут? Я хочу использовать make-initrd для создания рамдисков > для контейнеров. Это ведь совершенно непривилегированная операция. mkinitrd требовал его для создания устройств. make-initrd требует его (как минимум) для доступа к /lib/modules. > Ну и зря. В других дистрибутивах тоже делают ошибки и необоснованные > допущения. На мой взгляд это правильное допущение, иначе можно дойти до того, что предётся монтировать tmpfs в рабочую директорию (и то не поможет), потому что любым файловым операциям нельзя доверять. > На модули можно накладывать ограничения. Обоснуйте более веско необходимость накладывать ограничение в создании и выполнении временных скриптов и выполнении проверки на исполнимость. Это очень сильное ограничение и мне нужны очень веские доказательства того, что они необходимы. > Наличие атрибута u+x -- это необходимое, но не достаточное условие > исполнимости. а find -perm +0111 даёт достаточную гарантию исполнимости ? > Ты ведь знаешь, чем отличается проверка access(X_OK) от stat() с последующим > тестом на S_IXUSR|S_IXGRP|S_IXOTH. Какая тебе польза от этой разницы? Мы не знаем под каким пользователем и в каком контексте будет выполняться создаваемый образ. Так как я не имею достаточной информации я использую более простую и нативную проверку (необходимую, но не достаточную). > Вот код, о котором идёт речь: > for n in bash dash mksh ash; do > [ -x ./bin/$n ] || continue > ln -s /bin/$n ./bin/sh > break > done > > Возникают дополнительные вопросы: > - если ./bin/sh уже существует, то будет exit 1; Это ошибка. В следующей версии исправлю. > - если любой из вышеперечисленных файлов существует и является абсолютной > ссылкой, то проверка test -x может пройти, в то время как файл, на который > указывает ссылка, в образ не попадёт; put-file копирует не только симлинк, но и то на что он указывает (copy_file()). > - как был получен этот список шеллов? Это список шеллов, которые я смог вспомнить и которые поддерживают posix в достаточной мере чтобы выполнить скрипты initrd. > - зачем вообще нужен этот ./bin/sh? Чтобы иметь возможность писать #!/bin/sh в initrd.
К чему бы не привело это обсуждение, вы же все понимаете, что при поддержке модульности и при наличии хуков (сейчас они только внешние, но как знать что будет) гарантировать работоспособность initrd после сборки с noexec невозможно.
(In reply to comment #18) > (В ответ на комментарий №17) > > Такую гарантию никто не даст. > > Значит использование TMPDIR правомерно т.к. оно предназначено для хранения > временных файлов. Дополнительные ограничения на совести администратора. Да, но хранение и исполнение временных файлов -- это совершенно разные операции. > > А почему только рут? Я хочу использовать make-initrd для создания рамдисков > > для контейнеров. Это ведь совершенно непривилегированная операция. > > mkinitrd требовал его для создания устройств. > make-initrd требует его (как минимум) для доступа к /lib/modules. На тему этого доступа у нас, кстати, всё ещё висит баг #5969. Ладно, тут мы отвлеклись от темы. > > Ну и зря. В других дистрибутивах тоже делают ошибки и необоснованные > > допущения. > > На мой взгляд это правильное допущение, иначе можно дойти до того, что предётся > монтировать tmpfs в рабочую директорию (и то не поможет), потому что любым > файловым операциям нельзя доверять. Мы ведь говорим про совершенно реальную (и довольно распространённую в узких кругах) ситуацию. > > На модули можно накладывать ограничения. > > Обоснуйте более веско необходимость накладывать ограничение в создании и > выполнении временных скриптов и выполнении проверки на исполнимость. Это очень > сильное ограничение и мне нужны очень веские доказательства того, что они > необходимы. У нас ещё никто никогда в базовой системе не исполнял временные файлы. > > Наличие атрибута u+x -- это необходимое, но не достаточное условие > > исполнимости. > > а find -perm +0111 даёт достаточную гарантию исполнимости ? > > > Ты ведь знаешь, чем отличается проверка access(X_OK) от stat() с последующим > > тестом на S_IXUSR|S_IXGRP|S_IXOTH. Какая тебе польза от этой разницы? > > Мы не знаем под каким пользователем и в каком контексте будет выполняться > создаваемый образ. Так как я не имею достаточной информации я использую более > простую и нативную проверку (необходимую, но не достаточную). Проверка простая, с этим никто не спорит. И с тем, что она не является панацеей, тоже все согласны. Весь разговор о том, что эта проверка является не необходимой, а немного избыточной. Накладываются ограничения, без следования которым всё работало бы правильно. > > Вот код, о котором идёт речь: > > for n in bash dash mksh ash; do > > [ -x ./bin/$n ] || continue > > ln -s /bin/$n ./bin/sh > > break > > done > > > > Возникают дополнительные вопросы: > > > - если любой из вышеперечисленных файлов существует и является абсолютной > > ссылкой, то проверка test -x может пройти, в то время как файл, на который > > указывает ссылка, в образ не попадёт; > > put-file копирует не только симлинк, но и то на что он указывает (copy_file()). А если и то, на что он указывает, тоже ссылка? Например, /bin/bash, указывающий на bash3?
(In reply to comment #19) > К чему бы не привело это обсуждение, вы же все понимаете, что при поддержке > модульности и при наличии хуков (сейчас они только внешние, но как знать что > будет) гарантировать работоспособность initrd после сборки с noexec невозможно. Я не уверен, что можно гарантировать работоспособность initrd в принципе. Хорошо бы гарантировать, что initrd не получится неработоспособным именно из-за noexec на $TMPDIR, а ещё лучше -- сделать так, чтобы noexec на $TMPDIR вообще не влиял на make-initrd.
(В ответ на комментарий №20) > Да, но хранение и исполнение временных файлов -- это совершенно разные > операции. Да. Но и выполнение временных скриптов тоже правомерная операция в которой нельзя отказать. Несколько примеров касающиеся исполнения чего-либо в рабочем каталоге: mkimage исполняет сгенерированные скрипты для модификации образа; hasher исполняет сгенерированные скрипты для выполнения команд внутри образа. > На тему этого доступа у нас, кстати, всё ещё висит баг #5969. > Ладно, тут мы отвлеклись от темы. > Мы ведь говорим про совершенно реальную (и довольно распространённую в узких > кругах) ситуацию. Прощу привести доводы, почему > У нас ещё никто никогда в базовой системе не исполнял временные файлы. Исполнять скрипт и делать проверку на u+x разные вещи. И это всё равно не довод. Проблема #5969 не решена, но всё бывает в первый раз. > Проверка простая, с этим никто не спорит. И с тем, что она не является > панацеей, тоже все согласны. Весь разговор о том, что эта проверка является не > необходимой, а немного избыточной. Накладываются ограничения, без следования > которым всё работало бы правильно. В общем случае (следуя паранойе) проверка на -f ослабит конструкцию и тогда будет возможно положить симлинк /bin/bash который будет указывать на простой файл. То что ты предлагаешь не решение, а маскировка проблемы: "давайте не будем проверять на исполнимость т.к. проверка неудобна и пусть будет, что будет" > А если и то, на что он указывает, тоже ссылка? Например, /bin/bash, > указывающий на bash3? В этом случае он должен скопировать все симлинки до bash3.
(В ответ на комментарий №21) > Я не уверен, что можно гарантировать работоспособность initrd в принципе. Согласен и поэтому я стараюсь не ослаблять проверки без особой нужды. Плохо само получится. > Хорошо бы гарантировать, что initrd не получится неработоспособным именно > из-за noexec на $TMPDIR, а ещё лучше -- сделать так, чтобы noexec на $TMPDIR > вообще не влиял на make-initrd. Для этого проще всего вернуться к старому mkinitrd. Он не подразумевал расширения initrd ничем кроме копирования с разыменовыванием.
Дублирую сюда часть приватного письма. Есть программы, которым необходимо исполнять временные файлы, однако такие программы либо не являются базовыми, либо у них есть ручки для настройки. Возьмём тот же rpm, который сохраняет и исполняет %post-скрипты. У него есть макрос %_tmppath, который реализует эту настройку. У каждого пользователя может быть определено своё значение макроса %_tmppath. Если ты _настаиваешь_ на том, что make-initrd нужно уметь исполнять временные файлы, то сделай аналогичную ручку. Например, можно зарезервировать для этих целей какую-нибудь переменную среды, скажем, MKINITRD_TMPDIR. Использовать $TMPDIR в безусловном порядке плохо из-за того, что эта переменная слишком общего назначения, и предназначена она в основном для определения места для _хранения_ временных файлов утилитами вроде sort(1), а не места для _выполнения_ временных файлов.
(In reply to comment #23) > (В ответ на комментарий №21) > > > Хорошо бы гарантировать, что initrd не получится неработоспособным именно > > из-за noexec на $TMPDIR, а ещё лучше -- сделать так, чтобы noexec на $TMPDIR > > вообще не влиял на make-initrd. > > Для этого проще всего вернуться к старому mkinitrd. Он не подразумевал > расширения initrd ничем кроме копирования с разыменовыванием. На этой стадии развития уже проще пропатчить make-initrd.
По результатам приватного общения: Добавлена поддержка переменной окружения INITRD_WORKDIR, которая определяет каталог где будет создаваться образ. Логика следующая: WORKDIR="${INITRD_WORKDIR-}" WORKDIR="${WORKDIR:-${TMPDIR-}}" WORKDIR="${WORKDIR:-/tmp}" Плюс добавлена проверка на 'noexec' опцию.
(In reply to comment #26) > Плюс добавлена проверка на 'noexec' опцию. Спасибо! С меня причитается за вредность :) (In reply to comment #17) > > Разумеется это проверка важна. Я хочу быть уверенным, что в initrd я сделал > > симлинк на исполняемый файл, а не на обычный, потому что это ведёт к краху > > процесса загрузки. Так в багу вчитайся -- именно этой "уверенностью" в виде некорректного теста и привёл ко краху процесса загрузки. > Проверка test -x не даёт гарантии исполнимости даже в нативном контексте, не > говоря уже о чужом контексте. Мало того, /bin/sh может оказаться вообще не командным интерпретатором -- и что с того? Я бы если уж хочется обеспечить исполнимость в данном качестве -- то: 1) попытался бы выполнить простейший тест вида [ "$(sh -c "true && echo yes") = "yes" ] (на что могут быть архитектурные ограничения -- или нет?) 2) сделал бы chmod +x на уложенный для формирования образа экземпляр. (In reply to comment #18) > Значит использование TMPDIR правомерно т.к. оно предназначено для хранения > временных файлов. Дополнительные ограничения на совести администратора. Ну ты даёшь. Вот уж ради собственной блажи наказывать системного администратора, предпринявшего _разумную_ меру для его собственной системы -- это непрофессионализм. > > А почему только рут? > make-initrd требует его (как минимум) для доступа к /lib/modules. У меня ещё есть надежда сделать control для /boot и /lib/modules. :) > Обоснуйте более веско необходимость накладывать ограничение в создании и > выполнении временных скриптов и выполнении проверки на исполнимость. Это очень > сильное ограничение и мне нужны очень веские доказательства того, что они > необходимы. Я как администратор веб-серверов порой предпочитаю отбирать у apache возможность записи в /tmp, и считаю возможность для хоста смонтировать его с noexec большим плюсом.
(В ответ на комментарий №27) Как я уже сказал, поведение make-initrd не поменяется. Появилась проверка на корректность "test -x", выполнение скриптов в workdir и если таких возможностей у workdir нет, то будет отказ что-либо создавать в таком рабочем каталоге. Плюс тем, у кого такой супер безопасный каталог /tmp, сделана переменная, где все условия будут выполняться. Так что искать небезопасный каталог? доступный вызвавшему make-initrd, на безопасном сервере всё равно предётся, чтобы вы не говорили.
(В ответ на комментарий №27) Как я уже сказал, поведение make-initrd не поменяется. Появилась проверка на корректность "test -x", выполнение скриптов в workdir и если таких возможностей у workdir нет, то будет отказ что-либо создавать в таком рабочем каталоге. Плюс тем, у кого такой супер безопасный каталог /tmp, сделана переменная, где все условия будут выполняться. Так что искать небезопасный каталог, доступный вызвавшему make-initrd, на безопасном сервере всё равно предётся, чтобы вы не говорили.
(В ответ на комментарий №27) > > Значит использование TMPDIR правомерно т.к. оно предназначено для хранения > > временных файлов. Дополнительные ограничения на совести администратора. > Ну ты даёшь. Вот уж ради собственной блажи наказывать системного > администратора, предпринявшего _разумную_ меру для его собственной системы -- > это непрофессионализм. Хочу выделить это замечание, но оставлю его без комментариев дабы не усиливать обиду у обиженных и не обижать новых читателей. > считаю возможность для хоста смонтировать его с noexec большим плюсом. Считай. Теперь ты можешь монтировать хоть всю систему в readonly и сам придумывать где генерировать initrd. В общем, тему считаю исчерпанной. Ждите нового релиза.
*** Bug 24641 has been marked as a duplicate of this bug. ***
Написали много, а заявленную проблему так и не решили. 1. Такое поведение make-initrd по умолчанию запрещает использование noexec для /tmp (приводя к негрузящейся системе) 2. Вовсе не надо было так упираться в проверку исполнимости через test -x, она ничего сильного не делает, можно было и объехать. P.S. Если make-initrd ничего не создаёт вследствие какой-либо ошибки, grub потом получает запись для загрузки ядра просто без initrd.
Я бы в данном конкретном случае все равно заменил бы проверки [ ! -x ./bin/sh ] и [ -x ./bin/$n ] на [ -z "$(find -L ./bin/sh -maxdepth 0 -type f -perm -u=x 2>/dev/null)" ] и [ -n "$(find -L ./bin/$n -maxdepth 0 -type f -perm -u=x 2>/dev/null)" ] соответственно. Но сейчас там уже check_noexec, что обессмысливает эту замену, и я уже везде, где надо, давно использую INITRD_WORKDIR. Поскольку make-initrd непременно хочет иметь возможность исполнять временные файлы, это CLOSED FIXED.
