Я б не назвав це функцією безпеки.
Виконавчий файл може працювати за своїм єдиним іменем, якщо він знайдений в одному з каталогів, визначених PATHзмінною середовища. У моєму Debian 9 файл /etc/profileвизначає базове, PATHяк це:
if [ "`id -u`" -eq 0 ]; then
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
else
PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
fi
export PATH
Це означає, що для будь-якого користувача з UID 0(для мого Debian лише для root) типовим є
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
(каталоги розділені :) і для будь-якого іншого користувача це
PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
Я називаю це "за замовчуванням", тому що зазвичай /etc/profileзавантажується для будь-якого користувача, але тоді користувач може змінити свій власний PATH. Зазвичай ~/.profileце добре робити файл.
При запуску sudo some_command, sudoвикористовує ще один набір каталогів замість PATH. Цей набір може бути або не може бути визначений десь у sudoconfig ( /etc/sudoers, /etc/sudoers.d/*). Якщо це не визначено явно, /etc/sudoersговорить про те, що значення за замовчуванням є
secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
(Це дещо спрощено, інші параметри можуть змінити цю механіку; див. man 5 sudoersПодробиці).
Зауважте, що PATHдля rootта secure_pathвикористовуються sudoдекілька каталогів, названих sbin(у різних місцях), а PATHдля звичайних користувачів - ні. У цих довідниках є інструменти, призначені для використання в основному root.
Тож якщо sudo some_commandзнайти виконувану та підошву some_commandце не так, це тому, що some_commandвін знаходиться в одному з каталогів, які є, secure_pathале не у вашому PATH.
Але це не функція безпеки. Будь-який користувач може додати всі ці sbinкаталоги до своїх PATH, тому після введення some_commandоболонки спробує запустити виконуваний файл. Або вони можуть використовувати повний шлях на зразок /sbin/some_command. Реальні функції безпеки потім починають:
- права доступу до файлів можуть заборонити користувачам, які не користуються коренем, запускати його (хоча в Debian 9 багато виконуваних файлів (все?) може виконувати будь-який користувач);
- файл працює, але він не може отримати доступ до основних ресурсів, тому він видає помилку та виходить (наприклад
/sbin/hwclock);
- файл працює і використовує деякий агент автентифікації для підвищення дозволів без нього
sudo(такий файл, швидше за все, буде розміщений в binпершу чергу, наприклад /bin/systemd:);
- або файл працює успішно, тому що ви можете запустити його, незважаючи на те, що він знаходиться
sbin(наприклад, /sbin/discoverу моєму Debian).
Ваш обліковий запис користувача не налаштований some_commandбез роботи, sudoтому що як звичайному користувачеві він вам не потрібен. Але якщо ви все-таки хочете цього, просто скористайтеся його повним шляхом і отримайте його ( whereis some_commandможливо, це стане в нагоді). Населення ваших PATHцих sbinкаталогів лише заповнить вкладку (наприклад, у Bash).
Завершення вкладки заслуговує певного пояснення. Візьміть Bash як приклад оболонки з цією функціональністю. Оболонка має PATHсвоє оточення, вона може її читати, тому, якщо ви наберете another_comта натиснули tab, вона може дати вам підказку, що another_commandзнайдете десь відповідно до вашого PATH. Якщо some_commandдесь знаходиться sbin, some_com tabйого не знайдуть.
Ще sudo some_com tabможе знайти. Це може здатися дивним, оскільки оболонка не може знати root, PATHвона не може читати тощо /etc/sudoers. Що відбувається - оболонка тимчасово додає загальні sbinкаталоги PATHлише для здійснення цього пошуку. Це робиться всередині файлу /usr/share/bash-completion/completions/sudo, відповідний рядок
local PATH=$PATH:/sbin:/usr/sbin:/usr/local/sbin
Щоб відповісти на ваше явне запитання
Чи можна відключити цю функцію?
Так, ви можете додавати sbinдо себе каталоги PATH. Це не дозволить вам успішно запускати команди, sudoхоча вони справді потребують sudo(і багато хто робить).