Nei giorni di lavoro, vorrei eseguire
$ ./configure && make && sudo make install && halt
di notte e andare a letto, sperando che l'applicazione venga installata automaticamente. Ma quello che vedo il giorno dopo è la schermata in cui sudo mi chiede la password. Come potrei eseguire sudo con la password in una sola riga di comando, o c'è un altro metodo per farlo?
Sì, utilizzare l'interruttore -S che legge la password da STDIN:
$echo <password> | sudo -S <command>
``` ```
$./configure && make && echo <password> | sudo -S make install && halt
Quindi per il vostro caso sarebbe così:
&001 &001
naturalmente, sostituire <password> con la vostra password.
Molte delle altre soluzioni hanno lo svantaggio di eseguire inutilmente ./configure e make come root.
Questo è un po’ contorto, ma dovrebbe funzionare:
sudo sh -c "su $USER -c ./configure && su $USER -c make && make install && halt"
``` &001
Si noti l'uso di doppie virgolette per consentire l'espansione di `$USER` tramite il guscio (non root).
Potrei anche aggiungere un `sleep 60` prima del comando `halt`. A volte ho fatto cose del genere, aspettandomi che il comando funzioni per molto tempo, ma qualcosa va storto e termina immediatamente; l'`sleep` mi permette di uccidere il comando prima che il sistema si spenga. Oppure si può usare `shutdown` con un argomento di tempo.
Impostare HISTIGNORE su “sudo -S”
$ export HISTIGNORE='*sudo -S*'
e poi passare la password in modo sicuro a sudo:
$ echo "your_password" | sudo -S -k <command>
``` ```
$ export HISTIGNORE='*sudo -S*'
$ echo "<your_password>" | sudo -S -k whoami
$ echo "<your_password>" | sudo -S -k cat /etc/shadow
$ echo "<your_password>" | sudo -S -k bash /tmp/myscript.sh
“HISTIGNORE” significa non salvare questo comando nella cronologia. Questa è la cronologia in memoria o il file “~/.bash_history”.
Ad esempio, la seguente procedura consente di passare la password in modo sicuro al comando sudo, senza conservare la cronologia della password.
“-S”, significa utilizzare stdin per la password,
“-k” significa ignorare le credenziali memorizzate nella cache per costringere sudo a chiedere sempre. Questo è per un comportamento coerente.
$ export HISTIGNORE='*sudo -S*'
$ echo "<your_password>" | sudo -S -v
$ sudo whoami
$ echo "<your_password>" | sudo -S -v
$ sudo cat /etc/shadow
$ echo "<your_password>" | sudo -S -v
$ sudo /tmp/myscript.sh
``` &001
Il lato negativo del metodo di cui sopra è che se volete vedere i comandi che avete eseguito nella cronologia in seguito non ci saranno. Un altro metodo è quello di aggiornare la cache delle credenziali di autenticazione di sudo (il default è abilitato con un timeout di 5 minuti), quindi eseguire il sudo separatamente. Ma il lato negativo di questo è che si dovrà essere consapevoli della cache di 5 minuti.
Per esempio:
&001 &001
Nota Ho eseguito un sudo prima di ogni comando per assicurare che la cache del sudo sia aggiornata, dato che il valore predefinito è di 5 minuti. Sì, whoami non dovrebbe richiedere 5 minuti, ma penso che sia meglio farlo eseguire prima di ogni comando per coerenza. Si potrebbe anche mettere "export HISTIGNORE='_sudo -S_'" nel file ~/.bashrc, poi caricarlo con ". ~/.bashrc" o logoff e poi effettuare il login. Tuttavia, sto pensando di usare questo per scopi di scripting, quindi lo terrò in cima a tutti i miei script per le migliori pratiche di sicurezza. Impostare "echo "" | sudo -S -v" su una variabile invece potrebbe essere una buona idea, poi basta eseguire la variabile prima di ogni comando che necessita di privilegi di root, vedi il commento di Janar. Il commento di "John T" dovrebbe includere anche il parametro "-k", come se si eseguisse "sudo -S" senza "-k" e la cache di autenticazione sudo avesse già le proprie credenziali (ed è ancora valida, la cache di autenticazione sudo di default è di 5 minuti) allora bash eseguirà invece la password come comando, il che è un male.
Nota, ho scoperto che questo metodo non funziona su una vecchia versione di sudo, in particolare “Sudo versione 1.6.7p5”:
$ echo "<your_password>" | sudo -S -k whoami
Dove come questo metodo funziona su vecchie e nuove versioni sudo:
$ echo "<your_password>" | sudo -S -v
$ sudo whoami
Se si vuole fare più attenzione, si potrebbe fare uno script, modificare i permessi del file in modo che solo root possa leggere e modificare e poi semplicemente eseguirlo.
Esempio: 1) Creare un file:
gedit ~/.easy.install
2) Incollare e salvare:
./configure && make && echo <password> | sudo -S make install && halt
``` ```
sudo chmod +x ~/.easy.install
3) Renderlo eseguibile:
sudo chmod 700 ~/.easy.install
``` ```
~/.easy.install
4) Modificare i permessi del file in modo che solo root possa leggerlo e modificarlo:
&001
5) Eseguire:
&001
Enjoy ;-)
Impostare sudo in questo modo è pericoloso se a qualcuno capita di vedere il fatto che sudo non richiede una password sul tuo account. A meno che non sappiate cosa state facendo, non fatelo. Mi è capitato una volta di troppo nel mio programma locale di A+ Training con il mio computer sperimentale… -_-
Quello che ha detto John T. suona bene, però, se non fosse che c'è ancora il rischio di trovare la password nella storia della shell. Quello che ha detto CarlF suona meglio, ma se un comando fallisce, il computer continuerà a funzionare con privilegi da superutente.
Il problema è risolto. Per esempio, alla radice utente:
echo -e 'password\npassword\n' | sudo passwd root
Personalmente faccio abbastanza come John T ha risposto il 9 novembre ‘09 alle 2:47, ho anche migliorato la mia secondo la guida della sua risposta, grazie.
La differenza è che tendo a fare uso di variabili, qualcosa come:
AutoSuDo=$" $echo pass | sudo -S";
# Change AutoSuDo to something else.
# Note that string starts with space,
# useful only if used as first command in line
``` ```
$AutoSuDo apt-get update;
In questo modo posso facilmente usare la mia variabile invece di sudo,
&001 &001
Questo è abbastanza utile con alcuni script più lunghi. Faccio uso di questi principalmente per personal computer di altri, che devo mantenere.
Raccomando anche di fare attenzione a: