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

Коли я пишу сценарій оболонки, в якому деякі, але не всі команди в ньому потребують привілеїв суперпользователя, чи повинен я

• додайте sudo до тих команд, які потребують привілеїв суперпользователя, та запустіть скрипт оболонки без sudo, або

• не додайте sudo до тих команд, яким потрібні привілеї суперпользователя, але запустіть скрипт оболонки з sudo?

По-друге, мені потрібно буде ввести свій пароль лише один раз, але всі команди в скрипті будуть виконуватись з надповерховими привілеями, включаючи ті команди, які не потрібні.

По-перше, мені може знадобитися надати свій пароль кілька разів для різних команд sudo, тоді як привілеї суперпользователя надаються лише тим командам, які їм потрібні.

З точки зору безпеки, перший спосіб - краще. Для зручності краще другий спосіб.

1. Я думав прийняти перший спосіб. Тому мені доводиться стикатися з незручністю надання моїх паролів декільком командам sudo в сценарії оболонки.

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

   Добре написаний сценарій виявить, чи працює він з правильними дозволами і взагалі не викликає sudo, але дуже багато поганих сценаріїв

   Тож я повинен використовувати другий спосіб? Якщо так,

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

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

3. Чи буде цей простий підхід найкращим з обох підходів: додайте sudo до команд, які лише потрібні, та запускайте сценарій із судо або без нього, залежно від того, чи хочу я зручності чи безпеки? Чи має такий підхід певні проблеми?

Дякую.

Щоб вирішити свою першу проблему:

як я можу написати "скрипт виявив би, чи працює він з правильними дозволами і взагалі не викликає sudo"?

Існує проста та POSIX перевірка кореня:

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

Крім того, в Bash можуть використовувати більше кодери, орієнтовані на продуктивність:

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

Зауважте, що я навмисно загортав код у функції для повторного використання.

Щоб вирішити своє друге питання:

як я можу покращити її безпеку, щоб уникнути проблеми надання привілеїв суперрузера командам, які їм не потрібні під час запуску сценарію з sudo?

З цим не можна багато зробити. Принаймні нічого не спадає на думку. Якщо я побачив сценарій, у мене можуть бути пропозиції. Але оскільки ви не включили його у своє запитання ... Якщо ви запускаєте весь сценарій з sudoабо як root, я не бачу способу це контролювати.

Щоб звернутися до коментаря:

Як ви думаєте про "використання судо всередині нього проти запуску із судо"

У своїх сценаріях я, як правило, дію з останнім підходом, але це не обов'язково означає, що я рекомендую це вам. Тому що це залежить від того, для кого призначений сценарій - rootлише для цього ; для користувачів, за винятком випадків, коли деякі користувачі мають sudoправа; вам доведеться буквально включити ваш сценарій у запитання, щоб я міг відповісти з будь-яким значенням.

Я думаю, що можу відповісти на це.

Тож я повинен використовувати другий спосіб?

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

Якщо є лише одна команда, яку потрібно запустити як root, то runваша програма як rootабо sudoтому, що sudoвсередині вашого сценарію проходить довша дорога. Ви забули, що програмісти ліниві?

Якщо вам потрібно багато команд run, 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
how-do-i-define-if-a-shell-script-is-running-with-root-permissions

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....... моєї відповіді тут закінчується УФ