Skrypt powłoki: użyj sudo w środku vs uruchomić go z sudo?

Pisząc skrypt powłoki, w którym niektóre, ale nie wszystkie polecenia w nim potrzebują uprawnień administratora, powinienem:

• dodaj sudo do tych poleceń, które wymagają uprawnień administratora i uruchom skrypt powłoki bez sudo, lub

• nie dodajesz sudo do tych poleceń, które wymagają uprawnień administratora, ale uruchamiasz skrypt powłoki za pomocą sudo?

Po drugie, będę musiał podać hasło tylko raz, ale wszystkie polecenia w skrypcie będą uruchamiane z uprawnieniami administratora, w tym tymi, które nie potrzebują.

Po pierwsze, może być konieczne wielokrotne podanie hasła dla różnych poleceń sudo, podczas gdy uprawnienia administratora są przyznawane tylko tym, które ich potrzebują.

Ze względów bezpieczeństwa pierwszy sposób jest lepszy. Dla wygody drugi sposób jest lepszy.

1. Myślałem o przyjęciu pierwszego sposobu. Mam więc do czynienia z niedogodnością związaną z udostępnianiem haseł wielu poleceniom sudo w skrypcie powłoki.

2. Stephen Harris napisał :

   Dobrze napisany skrypt wykryje, czy działa z odpowiednimi uprawnieniami i w ogóle nie wywoła sudo, ale jest wiele złych skryptów

   Więc powinienem użyć drugiego sposobu? W takim razie,

   • jak napisać: „skrypt wykryłby, gdyby działał z odpowiednimi uprawnieniami i wcale nie wywoływał sudo”?

   • jak mogę poprawić jego bezpieczeństwo, aby uniknąć problemu z nadawaniem uprawnień superużytkownikowi komendom, które nie potrzebują ich podczas uruchamiania skryptu w sudo?

3. Czy to proste podejście miałoby najlepsze z obu podejść: dodaj sudo do poleceń, które go potrzebują, i uruchom skrypt z sudo lub bez, w zależności od tego, czy chcę wygodę czy bezpieczeństwo? Czy to podejście ma jakiś problem?

Dzięki.

Aby rozwiązać pierwszy problem:

jak napisać: „skrypt wykryłby, gdyby działał z odpowiednimi uprawnieniami i wcale nie wywoływał sudo”?

Istnieje proste i POSIX sprawdzenie roota:

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

Alternatywnie, w Bash, kodery o większej wydajności mogą chcieć użyć:

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

Zauważ, że celowo zapakowałem kod w funkcje do ponownego użycia.

Aby rozwiązać drugi problem:

jak mogę poprawić jego bezpieczeństwo, aby uniknąć problemu z nadawaniem uprawnień superużytkownikowi komendom, które nie potrzebują ich podczas uruchamiania skryptu w sudo?

Nie możesz wiele z tym zrobić. Przynajmniej nic nie przychodzi mi do głowy. Gdybym zobaczył scenariusz, mogę mieć sugestie. Ale ponieważ nie umieściłeś go w swoim pytaniu ... Jeśli uruchomisz cały skrypt za pomocą sudolub as root, nie widzę sposobu, aby to kontrolować.

Aby rozwiązać komentarz:

Co sądzisz o „używaniu sudo w środku vs uruchamianie go z sudo”

W moich skryptach zwykle stosuję to drugie podejście, ale to niekoniecznie oznacza, że ​​polecam ci to. Ponieważ zależy to od tego, dla kogo przeznaczony jest skrypt - roottylko dla ; dla użytkowników głównie z wyjątkiem posiadania przez niektórych użytkowników sudopraw; musiałbym dosłownie dołączyć swój skrypt do pytania, aby móc odpowiedzieć z dowolną wartością.

Myślę, że mogę na to odpowiedzieć.

Więc powinienem użyć drugiego sposobu?

Nie ma powodu, dla którego powinieneś mieć problem, oto powód:

Jeśli istnieje tylko jedna komenda, którą należy uruchomić jako root, wówczas runtwój program jako rootlub sudoponieważ sudow skrypcie jest dłuższa droga. Czy zapomniałeś, że programiści są leniwi?

Jeśli potrzebujesz wiele poleceń run, jak rootnastępnie uruchomić go jako rootlub sudo.

jak mogę poprawić jego bezpieczeństwo, aby uniknąć problemu z nadawaniem uprawnień superużytkownikowi komendom, które nie potrzebują ich podczas uruchamiania skryptu w sudo?

Jeśli inni użytkownicy potrzebują runTwojego programu, skonfiguruj sudoje, ponieważ sudomożna je łatwo dostosować do własnych potrzeb.

Oto przykład z sudo:

Zawsze używaj visudopodczas edycji pliku sudoers .....

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

sudo jest również świetny do zmiany użytkowników w twoim programie / skrypcie, oto wiersz z jednego ze moich skryptów:

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

jak napisać: „skrypt wykryłby, gdyby działał z odpowiednimi uprawnieniami i wcale nie wywoływał sudo”?

https://www.cyberciti.biz/tips/shell-root-user-check-script.html
jak-i-i-określić-jeśli-shell-skrypt-działa-z-root-uprawnieniami

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

EDYCJA na żądanie dżentelmena @terdon:

Pomyśl o swoim skrypcie w ten sposób ...

Czy jest to skrypt publiczny (inne osoby niż ty go użyjesz) Co robi skrypt? Czy to wskazuje godzinę? Czy aktualizuje iptables w 200 systemach? Jeśli tylko z niego korzystasz, to czy jest to związane z pracą / zawodem, czy jest do użytku osobistego?

Musisz tylko wiedzieć z góry, z czego składa się twoja grupa użytkowników, to wszystko.

Jeśli ma to writtendawać lub sprzedawać administratorom, nawet wtedy, dlaczego nie powinno scriptbyć dozwolone działanie jako root? Jaką szkodę może to zrobić?

Prawdziwe skrypty / programy działają często jako uprzywilejowany użytkownik i nikt nie wspomina, że ​​to nie problem, ale kiedy programiści, głównie nowicjusze tacy jak ja, mówią o tych rzeczach, to jest to prawdziwe zagrożenie bezpieczeństwa ..... co facet w twoim poście odesłanie to próba powiedzenia, choć nie elegancko jest to, że niektórzy ludzie patrzą na kontrolę, którą masz systemi twój kod ... czy ustawiasz pliki na więcej uprawnień, niż zamierzasz używać, czy masz wszystkie kontrole w swoim logika, czy utalentowany programista widzi w twoim kodzie niebezpieczeństwa, tylko na niego patrzy?

Jeśli twój code needs root, użyj sudo, a jeśli jest ich wiele, po prostu uruchom go jako root....... moja odpowiedź kończy się tutaj uff