Чому змінні PATH відрізняються під час роботи через sudo та su?

На моєму VM 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

Це забезпечує чистоту вашого шляху під час запуску бінарних файлів під судо. Це допомагає захиститись від деяких проблем, відзначених у цьому питанні . Це також зручно, якщо у вас немає /sbinі /usr/sbinна своєму шляху.

Команда su -виконає профіль користувача root і займеться в оточенні цього користувача, включаючи шлях тощо 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. Якщо ви не довіряєте людям, які керують судо, щоб мати здоровий звук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.

Я просто спробував це на собі, і я не бачив поведінки, яку ви бачили - мій шлях залишився колишнім, тому, можливо, ваша конфігурація судо інша. Якщо ви перевірите, 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 -. Звідки взялася ця частина ПАТ?

Після багатьох привітань і пошуку я знайшов відповідь:

Шлях за замовчуванням, що містить '/ usr / local / bin', насправді жорстко кодується в su (1).

Тому жодна конфігурація пам’яті, профіль, bashrc чи щось інше не відповідали за вибіркове додавання цього елемента. Це було завжди вже тоді, коли suперебирали. А оскільки sudoзовсім не посилається, suале використовує власну конфігурацію, після цього вона відсутняsudo -i

Я знайшов це правдою на RHEL6 та RHEL7. Я не перевіряв жодної іншої версії чи розповсюдження.