Ожидается ли такое поведение?
Да, действительно, это ожидаемое поведение. За него отвечают кэшированные учетные данные пользователя для sudo.
Возможно ли его конфигурирование?
Да, это настраивается.
И я думаю, что ваша озабоченность по поводу безопасности является действительной. Запуск script.sh в терминале, где команда sudo запускается до (в течение определенного таймаута), предоставит привилегию суперпользователя сценария, если скрипт написан с явными командами sudo.
Вы можете избежать любого сценария не запрос пароля при запуске, как Судо, запустив его с:
sudo -k script.sh
Он будет запрашивать пароль, независимо от какой-либо предыдущей SUDO команды/с или сессии.
И запустить скрипт.sh без sudo i.е только с script.sh и еще подскажите пароля для команды Sudo/с:
Вы можете изменить значение тайм-аута (длительность Судо поддерживает сеанс) постоянно:
запустить sudo visudo
Затем измените строку:
Defaults env_reset
к
Defaults env_reset,timestamp_timeout=0
Сохранить и выйти из (Ctrl + X, то Y)
Это гарантирует, что Sudo запросит пароль каждый раз, когда он запускается.
Или Если вы не хотите, чтобы изменить его навсегда и хотите, чтобы ваш скрипт запросит пароль, по крайней мере один раз (при сохранении сеанса), то вы можете изменить сценарий, как это:
sudo -k first-command-with-sudo
sudo second-command
sudo third
and so on
Этот скрипт будет запрашивать пароль хотя бы один раз, независимо от предыдущих sudo command/s или session.
В случае, если вы не знаете (или не имеют доступа к) содержание script.sh сценария (он может иметь команды SUDO внутри него или нет)
И вы хотите быть уверены, что любая команда sudo наверняка запросит пароль хотя бы один раз, а затем запустит sudo -K (столица K) перед запуском скрипта.
Теперь, если вы запустите script.sh, и если он содержит команду sudo, он обязательно запросит пароль.
В вашей сессии хранятся учетные данные. Когда вы запускаете скрипт как самостоятельно, они все еще кэшируются. Запустите сценарий в отдельном сеансе, чтобы избежать этого, и вы также можете настроить длину кеширования (также ограничьте то, что вы можете сделать с помощью 'sudo' вместо« всего »). –
, если все сценарии могут запрашивать учетные данные, в чем смысл использования sudo против сеанса суперпользователя в отношении безопасности? Создаете ли вы специальный пользователь для запуска скриптов, отличных от sudo, когда учетные данные будут кэшироваться? – edi9999
'sudo' гораздо более настраивается, чем просто позволить пользователю стать суперпользователем; ограничивая пользователя только определенными привилегированными командами, либо с паролем, либо без него. – chepner