Почему переменные PATH отличаются при запуске через sudo и su?

На моей виртуальной машине Fedora при работе с моей учетной записью у меня /usr/local/binна пути:

[justin@justin-fedora12 ~]$ env | grep PATH
 PATH=/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/justin/bin

И так же, когда работает su:

[justin@justin-fedora12 ~]$ su -
Password: 
[root@justin-fedora12 justin]# env | grep PATH
PATH=/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/justin/bin

Однако при запуске через sudoэтот каталог не находится в пути:

[root@justin-fedora12 justin]# exit
[justin@justin-fedora12 ~]$ sudo bash
[root@justin-fedora12 ~]# env | grep PATH
PATH=/usr/kerberos/sbin:/usr/kerberos/bin:/sbin:/bin:/usr/sbin:/usr/bin

Почему путь будет отличаться при запуске через sudo?

Посмотрите на /etc/sudoers. Файл по умолчанию в Fedora (как и в RHEL, а также в Ubuntu и аналогичных) содержит следующую строку:

Defaults    secure_path = /sbin:/bin:/usr/sbin:/usr/bin

Что гарантирует, что ваш путь чист при запуске исполняемых файлов под sudo. Это помогает защитить от некоторых проблем, отмеченных в этом вопросе . Это также удобно, если у вас нет /sbinи /usr/sbinна вашем собственном пути.

Команда su -выполнит профиль корневого пользователя и примет окружение этого пользователя, включая путь и т. Д., sudoЭтого не делает.

Если вы хотите sudoвести себя так, su -используйте опцию, sudo -i [commandкоторая будет выполнять профиль пользователя

Если вы хотите su -вести себя так sudo, не используйте дефис - просто используйтеsu [command]

Вы можете проверить, почему (это отличается), запустив sudo sudo -V.

Например, в Linux запустите:

$ sudo sudo -V | grep PATH
Value to override user's $PATH with: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

^{Примечание: В MacOS / BSD, просто запустите: sudo sudo -V.}

Приведенный выше список ограничен из-за плагина политики безопасности по умолчанию в некоторых дистрибутивах Linux.

Это дополнительно объясняется в man sudoers:

Если secure_pathопция установлена, ее значение будет использоваться для PATHпеременной среды.

secure_path- Путь, используемый для каждой команды, запускаемой из sudo. Если вы не доверяете людям, работающим с sudo, иметь PATHпеременную среды, вы можете использовать это.

Другое использование, если вы хотите, чтобы «корневой путь» был отделен от «пути пользователя». Пользователи в группе, указанной exempt_groupпараметром, не затрагиваются secure_path. Эта опция не установлена ​​по умолчанию.

В этом случае вы можете изменить это, запустив sudo visudoи отредактировав файл конфигурации и изменив свой secure_path(добавив дополнительный путь, разделенный :) или добавив в него своего пользователя exempt_group(чтобы параметры не влияли на вас secure_path).

Или, чтобы пропустить PATHвременный пользователь , вы можете запустить:

sudo env PATH="$PATH" my_command

и вы можете проверить это:

sudo env PATH="$PATH" env | grep ^PATH

Смотрите также: Как сделать sudoконсерв $PATH?

Другая причина, по которой среда может отличаться sudo, заключается в том, что env_resetв вашем sudoersфайле может быть включена опция . Это заставляет команды выполняться в новой, минимальной среде.

Таким образом, вы можете использовать env_keepопцию (не рекомендуется из соображений безопасности ), чтобы сохранить переменные окружения вашего пользователя:

Defaults        env_reset
Defaults        env_keep += "PATH PYTHONPATH"

В большинстве linux вы устанавливаете программы через управление пакетами и регулярно получаете обновления. Если вы устанавливаете что-либо, обходящее управление пакетами, оно будет установлено в / usr / local / bin (например, или ... / sbin, или / opt) и не получит регулярных обновлений.

Поэтому я полагаю, что программы не считаются настолько безопасными и по умолчанию не помещаются в корень PATH.

Я только что попробовал это для себя, и я не видел поведение, которое вы видели - мой путь остался прежним, так что, возможно, ваша конфигурация sudo отличается. Если вы проверите, man sudoersто увидите, что есть опция, secure_pathкоторая перезагружается PATH- похоже, эта опция была включена.

Потому что, когда вы используете sudo bash, bashне действует как оболочка входа в систему. Попробуйте еще раз, sudo bash -lи вы увидите тот же результат, что и su -.

Если это верно, то разница в PATHложь в файлах конфигурации: /etc/profile, ~/.bash_profile, ~/.bash_login, ~/.profileвыполняются (в указанном порядке) для входа в оболочку, в то время как ~/.bashrcвыполняется для нерегистрированной интерактивной оболочки.

Старый вопрос, я знаю, но я наткнулся здесь только сейчас, потому что я исследовал именно эту проблему.

По какой-то причине /usr/local/binбыл только в PATH при получении root через sudo su -. При использовании sudo -iего там не было. Конечно, теперь я знаю, что могу добавить его в / etc / sudoers, но это все еще не объясняет, почему оно уже там su -. Откуда взялась эта часть PATH?

После долгих поисков я нашел ответ:

Путь по умолчанию, содержащий «/ usr / local / bin», фактически жестко запрограммирован в su (1).

Поэтому никакая конфигурация pam, профиль, bashrc или что-либо еще не отвечали за выборочное добавление этого элемента. Он всегда был там, когда suвступил во владение. А так sudoкак не вызывает suвообще, но использует свою собственную конфигурацию, послеsudo -i

Я нашел это, чтобы быть правдой на RHEL6 и RHEL7. Я не проверял ни одну другую версию или дистрибутив.