/ usr / bin / env как shebang – и его последствия для безопасности

В нескольких местах я видел совет, чтобы использовать следующую линию shebang

#!/usr/bin/env bash 

вместо

 #!/usr/bin/bash 

Моя реакция на коленный рефлекс: «Что, если кто-то заменит этот исполняемый файл своими словами в ~/.local/bin ?» Этот каталог часто настраивается на пути пользователя до общесистемных путей. Я вижу, что это поднималось как проблема безопасности часто как побочная заметка, а не что-то серьезно, но я хотел проверить теорию.

Чтобы попробовать это, я сделал что-то вроде этого:

 echo -e "#!/usr/bin/python\nprint 'Hacked!'" > $HOME/.local/bin/bash chmod 755 $HOME/.local/bin/bash PATH=$HOME/.local/bin env bash 

Это дает

 /usr/bin/env: 'bash': No such file or directory 

Чтобы проверить, собирался ли он вообще что-либо, я также сделал

 echo -e "#!/usr/bin/python\nprint 'Hacked!'" > $HOME/.local/bin/perl chmod 755 $HOME/.local/bin/perl PATH=$HOME/.local/bin env perl 

который печатает, как я ожидал,

 Hacked! 

Может кто-нибудь объяснить мне, почему замена bash не найдена, но заменитель perl есть? Является ли это своего рода мерой «безопасности», которая (с моей точки зрения) не подходит?

EDIT: Потому что мне было предложено: я не спрашиваю, как /usr/bin/env bash отличается от использования /bin/bash . Я задаю вопрос, как указано выше.

EDIT2: Должно быть, это было то, что я делал неправильно. Пробовал снова сегодня (используя явный путь к env вместо неявного) и такого поведения «не найдено».

  • получить переменную окружения по имени переменной?
  • Последняя неудачная команда в bash
  • Экспортировать переменную env, которая будет доступна во всех суб-оболочках, и может быть изменена?
  • лучший способ настроить отдельную среду Linux в ~
  • Ограничение опции grep --color для интерактивной оболочки
  • Msgstr "недействительный идентификатор", когда я делаю "экспорт $ PATH"
  • Получить значение переменных среды в for-loop
  • Как найти библиотеки, которые эта программа нуждается в переменной окружения?
  • 3 Solutions collect form web for “/ usr / bin / env как shebang – и его последствия для безопасности”

    «Что, если кто-то заменит этот исполняемый файл своими собственными словами ~ / .local / bin?

    Тогда сценарий для них не работает.

    Но это не имеет значения, поскольку они могли бы, по-видимому, разбить сценарий для себя другими способами или запустить другую программу напрямую, не испортив PATH или env .

    Если у ваших пользователей нет каталогов других пользователей в их PATH или вы можете редактировать PATH других пользователей, нет никакой возможности, чтобы один пользователь возился с другим.


    Однако, если это не сценарий оболочки, а что-то, что предоставляет дополнительные привилегии, такие как обертка setuid для некоторой программы, тогда все будет по-другому. В этом случае необходимо будет использовать абсолютный путь для запуска программы, поместить ее в каталог, который непривилегированные пользователи не смогут изменить, и очистить среду при запуске программы.

    Что касается разницы в поведении между оболочкой и perl , perl отличие от оболочки проверяет первую строку, чтобы определить, что нужно запускать:

     $ cat tcl #!/usr/bin/env tclsh puts "TCL running as [pid]" $ perl tcl TCL running as 39689 $ cat sbcl #!/opt/local/bin/sbcl --script (format t "~a running as ~a~%" 'lisp (sb-unix:unix-getpid)) $ perl sbcl LISP running as 39766 $ 

    Использование этой функции включает в себя написание тестов на каком-то другом языке, кроме perl, поэтому вы можете иметь TAP-совместимые скрипты на других языках и prove или что-то делать правильно.

    Здесь нет риска для безопасности. /usr/bin/env должен выбрать соответствующий двоичный файл в соответствии с окружением пользователя. Поэтому, если пользователь установил свой собственный bash в ~/.local/bin , то /usr/bin/env действительно должен попытаться его использовать (они могут, например, скомпилировать версию с дополнительными функциями, которые недоступны в общесистемной версии, и предпочла бы использовать ее вместо общесистемной версии). То же самое относится к любому другому двоичному / интерпретатору. Нет риска для безопасности, поскольку пользователь не сможет запускать все, что им не удалось бы запустить в любом случае.

    Что касается того, почему замена в вашем случае не подходит, я сомневаюсь, что это имеет какое-либо отношение к /usr/bin/env . Попробуйте запустить PATH=~/.local/bin bash , PATH=~/.local/bin bash <path-to-script> (как он будет вызываться при запуске скрипта) и PATH=~/.local/bin /usr/bin/env bash и посмотреть, кто из них не работает. Это должно дать представление о том, к чему относится ошибка «файл не найден».

    Linux и Unix - лучшая ОС в мире.