Jak sprawić, by sudo nie wygasło podczas działania skryptu [duplikat]
Czasami muszę uruchamiać skrypt godzinami, podczas których niektóre polecenia wymagają sudo
. Jeśli jednak nie sprawdzam i nie wprowadzam sudo
okresowo hasła, pojawia się sudo: timed out reading password
błąd, który czasami psuje całość. Nie chcę używać, sudo myscript.sh
ponieważ niektóre polecenia powinny być uruchamiane bez sudo
.
Chciałbym, aby sudo
hasło zapisane w pamięci podręcznej zachowało się dla skryptu przez cały czas trwania skryptu bez zmiany reszty systemu ( sudo
trwałość tylko dla tego 1 skryptu).
Czy jest sposób, aby sudo
trwać przez cały czas trwania skryptu i tylko na 1 scenariusz?
Odpowiedzi
Możliwość: uruchom skrypt z sudo myscript.sh
. Wewnątrz skryptu uruchom polecenia, które powinny być uruchamiane bez sudo
tego sposobu:
sudo -u "$SUDO_USER" foo args
(może z odpowiednią logiką na wypadek, gdyby cały skrypt był kiedykolwiek uruchomiony bez sudo
). Użytkownik root nie musi się uwierzytelniać sudoi jako taki nie musi wprowadzać hasła, aby wykonać polecenie jako inny użytkownik .
W zależności od tego, jak duży jest skrypt (jak bardzo trzeba go zmienić) i jak się czujesz, prowadząc z nim całość, sudo
pomysł może Ci się spodobać lub nie. W obecnym podejściu kod bez podwyższonych uprawnień jest domyślny, a wiersze sudo
są jawnymi wyjątkami. Moje podejście wywraca to do góry nogami. Musisz być bardziej ostrożny podczas tworzenia i testowania skryptu. Przyznaję, że to nie jest najlepsza praktyka; nadal rozwiązuje problem wygaśnięcia sudo
.
Osobiście użyłbym tego rozwiązania dla długo działającego skryptu, który nie jest zbyt skomplikowany (prosta pętla, kilka poleceń). Zastanowiłbym się jednak dwa razy, zanim przebudowałbym skomplikowany skrypt.
Innym podejściem jest okresowe aktualizowanie w tle poświadczeń zapisanych w pamięci podręcznej. Domyślnie są to per tty (zobacz tty_tickets). Postępuj w ten sposób:
sudo -v # to enter your password once
while sleep 300; do sudo -v; done & # adjust the interval if needed
myscript.sh
Nie zapomnij zabić pracy w tle, gdy nie jest już potrzebna. Sam skrypt może rozpocząć taką pracę; wtedy prawdopodobnie będziesz chciał, aby jakieś pułapki w skrypcie automatycznie zabijały zadanie po zakończeniu działania skryptu.