Почему переменные ПУТИ отличаются при выполнении через sudo и su?

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

Имущество (устройство псевдотерминала) является оконечным устройством, которое эмулировано другой программой (пример: xterm, screen, или ssh такие программы). pts является ведомой частью имущества.

(Больше информации может быть найдено в man pty.)

Краткое изложение:

Имущество создается процессом через posix_openpt() (который обычно открывает специальное устройство /dev/ptmx), и составлен парой двунаправленных устройств посимвольного ввода-вывода:

  1. Основная часть, которая является дескриптором файла, полученным этим процессом через этот вызов, используется для эмуляции терминала. После некоторой инициализации вторая часть может быть разблокирована с unlockpt(), и ведущее устройство используется, чтобы получить или отправить символы в эту вторую часть (ведомое устройство).

  2. Ведомая часть, которая привязывается в файловой системе как /dev/pts/x (настоящее имя может быть получено ведущим устройством через ptsname() ) ведет себя как собственное оконечное устройство (/dev/ttyx). В большинстве случаев оболочка запускается, который использует ее в качестве терминала управления.

42
24.12.2015, 19:17
7 ответов

Смотрите на /etc/sudoers. Файл по умолчанию в Fedora (а также в RHEL и также Ubuntu и подобный) включает эту строку:

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

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

38
27.01.2020, 19:35
  • 1
    , я вижу это в своем файле. Так, не, что я хочу, но если я добавил /usr/local/bin к этой директиве затем я видел бы его в своем пути при выполнении через sudo, право? –  Justin Ethier 05.03.2011, 18:25
  • 2
    я просто попробовал его и теперь я вижу /usr/local/bin. Огромное спасибо за объяснение этого! –  Justin Ethier 05.03.2011, 18:27
  • 3
    Что относительно того, чтобы добавить путь Ваших пользователей для сценариев и двоичных файлов, таким образом, Вы не должны писать полный путь, когда Вы должны sudo например, сценарий в Вашем ~/bin (или безотносительно пути Вы используете)? Я просто внес изменение - оно работает, только думал, что мог бы быть оборот к нему? –  Emanuel Berg 15.10.2012, 05:01
  • 4
    @mattdm Да, Ubuntu также, когда я столкнулся с той проблемой в Ubuntu, Яркой при проигрывании с VM. То же для Debian. –  kenorb 24.12.2015, 19:22

Команда su - выполнится пользователи root представляют и берут среду того пользователя включая путь и т.д. sudo не делает этого.

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

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

9
27.01.2020, 19:35

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

Я предполагаю поэтому, что программы не считаются, это защищает и не помещать в корневой ПУТЬ по умолчанию.

1
27.01.2020, 19:35
  • 1
    +1 - Прохладный, я задавался вопросом, почему это не было в пути, и это имеет смысл. Если это имеет значение я создавал node.js с нуля для проигрывания вокруг с ним, таким образом, это имеет смысл, почему это было бы помещено там, и почему sudo исключил бы этот каталог по умолчанию. –  Justin Ethier 05.03.2011, 18:29
  • 2
    @Justin Ethier: вне темы, но посмотрите bugzilla.redhat.com/show_bug.cgi?id=634911 –  mattdm 06.03.2011, 20:53

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

1
27.01.2020, 19:35
  • 1
    Интересный. Это было на Fedora 12, если это имеет значение... А-ч –  Justin Ethier 05.03.2011, 18:22

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

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

1
27.01.2020, 19:35

Вы можете проверить почему (это разные вещи), выполнив 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"
2
27.01.2020, 19:35

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

По какой-то причине /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. Я не проверял никакую другую версию или дистрибутив.

1
27.01.2020, 19:35

Теги

Похожие вопросы