сценарий оболочки: использовать внутри него sudo против запуска с sudo?

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

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

• не добавлять sudo к тем командам, которым нужны привилегии суперпользователя, но запускать сценарий оболочки с помощью sudo?

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

Во-первых, мне может понадобиться несколько раз предоставить свой пароль для разных команд sudo, в то время как привилегии суперпользователя предоставляются только тем командам, которые в них нуждаются.

Из соображений безопасности первый способ лучше. Для удобства лучше второй способ.

1. Я думал о принятии первого пути. Поэтому мне приходится иметь дело с неудобством предоставления моих паролей для нескольких команд sudo в сценарии оболочки.

2. Стивен Харрис написал :

   Хорошо написанный сценарий обнаружит, работает ли он с нужными разрешениями, и вообще не вызовет sudo, но есть много плохих сценариев.

   Так я должен использовать второй способ? Если так,

   • Как я могу написать «скрипт будет обнаруживать, если он работает с правильными разрешениями и вообще не вызывает sudo»?

   • Как я могу улучшить его безопасность, чтобы избежать проблемы предоставления привилегий суперпользователя командам, которым они не нужны при запуске сценария с помощью sudo?

3. Будет ли этот простой подход иметь лучшее из обоих подходов: добавить sudo к командам, которые только в этом нуждаются, и запустить сценарий с или без sudo в зависимости от того, хочу ли я удобство или безопасность? Есть ли у этого подхода проблемы?

Спасибо.

Для решения вашей первой проблемы:

Как я могу написать «скрипт будет обнаруживать, если он работает с правильными разрешениями и вообще не вызывает sudo»?

Существует простая проверка POSIX для root:

#!/bin/sh
is_user_root ()
{
    [ "$(id -u)" -eq 0 ]
}

В качестве альтернативы, в Bash могут использовать кодеры, ориентированные на производительность:

#!/bin/bash
is_user_root ()
{
    [ ${EUID:-$(id -u)} -eq 0 ]
}

Обратите внимание, что я намеренно обернул код в функции для повторного использования.

Для решения вашей второй проблемы:

Как я могу улучшить его безопасность, чтобы избежать проблемы предоставления привилегий суперпользователя командам, которым они не нужны при запуске сценария с помощью sudo?

Вы не можете ничего с этим поделать. По крайней мере, мне ничего не приходит в голову. Если бы я увидел сценарий, у меня могли бы быть предложения. Но так как вы не включили его в свой вопрос ... Если вы запускаете весь скрипт с помощью sudoили как root, я не вижу способа контролировать это.

Чтобы ответить на комментарий:

Что вы думаете об «использовать sudo внутри него против запуска с sudo»

В моих сценариях я обычно использую последний подход, но это не обязательно означает, что я рекомендую его вам. Потому что это зависит от того, для кого предназначен скрипт - rootтолько для ; для пользователей в основном за исключением того, что некоторые пользователи имеют sudoправа; Вы должны были бы буквально включить свой сценарий в вопрос, чтобы я мог ответить с любым значением.

Я думаю, что могу ответить на это.

Так я должен использовать второй способ?

Нет никаких причин, почему у вас должны быть проблемы здесь, вот почему:

Если есть только одна команда, которую нужно запустить от имени пользователя root, то runваша программа как rootили sudoпотому что sudoвнутри вашего скрипта более длинная дорога. Вы забыли, что программисты ленивы?

Если вам нужно много команд runas, rootзапустите его как rootили sudo.

Как я могу улучшить его безопасность, чтобы избежать проблемы предоставления привилегий суперпользователя командам, которым они не нужны при запуске сценария с помощью sudo?

Если другие пользователи нуждаются в runвашей программе, тогда настройте sudoих, потому sudoчто они очень настраиваемы и будут соответствовать вашим потребностям.

Вот пример с sudo:

Всегда используйте visudoпри редактировании файла sudoers .....

kate ALL=(ALL) NOPASSWD: /usr/local/bin/script ARG1 ARG2

sudo также отлично подходит для смены пользователей внутри вашей программы / скрипта. Вот строка из одного из моих скриптов:

sudo -i -u "$user" user="$user" CURRENTDIR="$CURRENTDIR" BASHRC="$BASHRC" bash <<'EOF'

Как я могу написать «скрипт будет обнаруживать, если он работает с правильными разрешениями и вообще не вызывает sudo»?

https://www.cyberciti.biz/tips/shell-root-user-check-script.html
инструкции "как сделать, если определите, если сценарий оболочки работает с правами root"

bash/sh:

#!/bin/bash
# (Use #!/bin/sh for sh)
if [ `id -u` = 0 ] 
then
        echo "I AM ROOT, HEAR ME ROAR"
fi

csh:

#!/bin/csh
if ( `id -u` == "0" ) 
then
        echo "I AM ROOT, HEAR ME ROAR"
endif

#!/bin/bash
if [[ $EUID -ne 0 ]]; then
  echo "You must be a root user" 2>&1
  exit 1
else
  mount /dev/sdb1 /mnt/disk2
fi

РЕДАКТИРОВАТЬ по запросу от джентльмена @terdon:

Подумайте о вашем сценарии так ...

Это публичный сценарий (другие люди, чем вы будете его использовать) Что делает сценарий? Это говорит вам время? Или он обновляет iptables на 200 системах? Если вы им пользуетесь, это связано с работой / профессией или для личного пользования?

Вам просто нужно заранее знать, из чего состоит ваша группа пользователей, и все.

Если даже writtenдля того, чтобы давать или продавать админам, почему бы не scriptразрешить запускать как root?? Какой вред это может сделать?

Реальные сценарии / программы часто запускаются как привилегированный пользователь, и никто не упоминает, что это не проблема, но когда программисты, в основном новички, такие как я, говорят об этих вещах, тогда это настоящая угроза безопасности ..... какой парень в вашем посте вы « Я имею в виду» пытается сказать, хотя это не так элегантно, это то, что некоторые люди смотрят на ваш контроль над systemвашим кодом и вашим кодом ... Вы устанавливаете файлы с более широкими правами, чем собираетесь использовать, у вас есть все проверки в вашем логика или талантливый программист увидит в вашем коде опасности, просто взглянув на него?

Если ваш code needs root, используйте sudo, и если есть много, просто запустите его как root....... мой ответ заканчивается здесь фу