Risposte:
Il problema è che sudo -s
senza alcun argomento si aprirà una shell interattiva per root.
Se vuoi semplicemente eseguire un singolo comando utilizzando sudo -s
, puoi semplicemente fare:
sudo -s command
Per esempio :
$ sudo -s whoami
root
Oppure puoi usare qui le stringhe:
$ sudo -s <<<'whoami'
root
Se hai più comandi puoi usare qui doc:
$ sudo -s <<'EOF'
> whoami
> hostname
> EOF
root
something--
Un altro modo sarebbe quello di passare un comando bash completo a sudo
:
#!/bin/bash
sudo bash -c 'command1; command2; command3;'
Tuttavia, un modo migliore sarebbe quello di avviare lo script con sudo
invece. Non è una buona idea avere sudo
all'interno della sceneggiatura. Molto meglio eseguire l'intero script con i privilegi di root ( sudo script.sh
). Se necessario, è possibile utilizzare sudo
per eliminare i privilegi per comandi specifici. Per esempio:
#!/usr/bin/env bash
whoami
echo $HOME
sudo -u terdon whoami ## drop privileges for specific command.
L'esecuzione dello script sopra restituisce:
$ sudo ~/scripts/a.sh
root
/root
terdon
La shell Bourne ha una -c
bandiera che puoi usare per passare uno script arbitrario alla shell, in modo da poter scrivere qualcosa del genere
sudo sh -c 'something'
Questo è tuttavia utile solo per i comandi più semplici, perché è molto ingombrante citare correttamente lo script e l'inconveniente è ancora maggiore se si invia il comando a un server remoto su ssh perché lo script dell'argomento verrà analizzato due volte, una volta sul lato inviando lo script e una volta sul lato eseguendo lo script.
Se something
è uno script complesso o deve essere passato su una riga ssh , è pratica comune scrivere una funzione il prepare_something_script
cui compito è scrivere lo script "qualcosa" su stdout . Nella sua forma più semplice, questa funzione può usare un documento qui per generare il suo output:
prepare_something_script()
{
cat <<EOF
something
EOF
}
Lo script prodotto da prepare_something_script
può quindi essere eseguito localmente con i privilegi concessi da sudo come segue:
prepare_something_script | sudo sh
Nello scenario in cui lo script deve essere eseguito in remoto con i privilegi concessi da sudo è consuetudine codificare lo script in base 64 per evitare di reindirizzare l'input standard di ssh , in questo modo:
something64=$(prepare_something_script | base64)
ssh usesr@remote-host "echo ${something64} | base64 --decode | sudo sh"
Se si utilizza il codice in una funzione, non dimenticate di segnare il something64 variabile come locale . Alcune implementazioni di base64 offrono un -d
flag da decodificare, che è meno ben supportato rispetto alla --decode
variante dettagliata . Alcune implementazioni richiedono di aggiungere -w 0
a al comando di codifica per evitare interruzioni di riga spurie.
sudo -s
nel caso in cui l'root
utente abbia avuto l'idea (piuttosto scadente) di cambiare shell. Questo dovrebbe davvero essere ciòsudo sh
che afferma esplicitamente quale shell deve essere usata.