(В ответ на комментарий №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.