Linux / Comando sudo: privilegi, sudoers e visudo

sudo consente a un utente autorizzato dalla politica di sicurezza di eseguire un comando con i privilegi di un altro utente. Senza un utente di destinazione esplicito, normalmente viene usato root; i comandi consentiti e il metodo di autenticazione dipendono comunque dalla configurazione del sistema.

È utile per installare pacchetti o gestire servizi, ma un errore può interessare l'intero sistema. Prima di eseguire un comando, controlla opzioni e percorsi e limita i privilegi alle sole operazioni necessarie.

Che cos'è il comando sudo?

sudo non assegna automaticamente privilegi amministrativi a chiunque lo usi: verifica chi può eseguire quale comando, su quale host e con l'identità di quale utente. Se la richiesta è consentita, effettua l'eventuale autenticazione ed esegue il comando autorizzato.

Nell'implementazione originale, il modulo di politica predefinito è sudoers, che normalmente legge /etc/sudoers e gli eventuali file inclusi da /etc/sudoers.d/. Sono possibili anche configurazioni centralizzate: non dare per scontato che tutte le regole siano in un singolo file locale.

Il manuale di sudo descrive l'esecuzione, mentre il manuale di sudoers documenta la sintassi delle regole.

Sintassi di base e prima esecuzione

La forma generale è la seguente. options, command e arguments sono segnaposto da sostituire, non un comando da incollare così com'è.

sudo [options] command [arguments...]

Su Debian o Ubuntu, questo esempio aggiorna l'indice dei pacchetti; non installa gli aggiornamenti disponibili. Richiede accesso alla rete e modifica l'indice locale, quindi va eseguito solo se è l'operazione desiderata.

sudo apt update

Quando occorre autenticarsi, in genere viene chiesta la password dell'utente che invoca sudo, non quella di root. La politica può però prevedere la password di un altro account o un altro metodo. In caso di successo, l'operazione amministrativa è eseguita con i privilegi di destinazione: la shell da cui hai lanciato il comando rimane quella dell'utente corrente.

La visualizzazione della password varia: alcune configurazioni non mostrano alcun carattere, mentre Ubuntu 26.04 abilita il riscontro visivo dell'inserimento in sudo-rs. L'assenza di caratteri sullo schermo, da sola, non indica un blocco.

sudo-rs è un'implementazione distinta, usata da alcune distribuzioni. Non offre tutte le opzioni e le funzioni di sudo originale: per esempio, la documentazione del progetto sudo-rs segnala che sudo -E non è supportato. Le descrizioni seguenti fanno riferimento a sudo originale; verifica il manuale e la versione installati prima di trasferirle a un'altra implementazione.

Opzioni di sudo più usate

Eseguire un comando come un altro utente

Selezionare l'utente con -u

Per un normale comando senza -u, l'utente di destinazione è generalmente root, salvo diversa configurazione. Con -u puoi scegliere un altro account consentito dalla politica.

sudo -u postgres psql

L'esempio avvia il client PostgreSQL come postgres: presuppone che l'account e il programma psql esistano. È utile per rispettare i permessi dei file di un servizio, ma il cambio di utente non garantisce automaticamente una connessione al database: contano anche configurazione e autenticazione di PostgreSQL. Alcuni account di servizio hanno inoltre una shell di login limitata.

Verificare l'identità effettiva

Se la politica lo consente, id mostra l'identità e i gruppi del processo avviato.

sudo id

sudo -u postgres id

I valori dipendono dagli account configurati: nel primo caso ci si aspetta normalmente l'identità root, nel secondo quella di postgres. Non copiare UID e gruppi da un altro sistema come se fossero universali. Se la richiesta è negata, non cambiare le regole solo per eseguire questa verifica: chiedi all'amministratore quale controllo è autorizzato.

Permessi consentiti e cache di autenticazione

Controllare le autorizzazioni con sudo -l

sudo -l elenca le impostazioni e i comandi consentiti all'utente corrente. In caso di errore di autorizzazione, è il primo controllo da fare prima di tentare modifiche alla configurazione.

sudo -l

Leggi anche l'utente di destinazione e gli argomenti ammessi: essere autorizzati a un comando non implica poterlo eseguire con qualunque parametro. Un amministratore con privilegi appropriati può consultare quelli di altri utenti con -U; un utente normale controlla generalmente i propri.

Rinnovare l'autenticazione con sudo -v

sudo -v verifica o rinnova le credenziali memorizzate senza eseguire un comando amministrativo. Può richiedere la password se necessario.

sudo -v

Durata e ambito della cache dipendono dalla politica. Non ricevere una nuova richiesta di password per un certo periodo non significa avere accesso a tutti i comandi: ogni richiesta continua a essere confrontata con le regole.

Invalidare la cache con sudo -k e -K

Usato da solo, sudo -k invalida la registrazione di autenticazione associata alla sessione corrente. È utile al termine di un'attività amministrativa.

sudo -k

Nel sudo originale, -K elimina tutte le registrazioni dell'utente, comprese quelle associate ad altri terminali o processi padre. La differenza concreta dipende dal tipo di timestamp configurato. Nessuna delle due opzioni revoca i permessi né modifica NOPASSWD: una password sarà richiesta al prossimo uso soltanto se la politica la richiede. Anche dopo aver invalidato la cache, blocca o chiudi un terminale condiviso.

Concatenazioni di comandi e pipe

sudo si applica al comando che avvia

Nel seguente esempio solo apt update viene avviato tramite sudo. Se riesce, apt upgrade viene eseguito dalla shell con i normali privilegi dell'utente corrente.

sudo apt update && apt upgrade

Se entrambe le operazioni richiedono privilegi amministrativi, specifica sudo per ciascuna. apt upgrade installa aggiornamenti: valuta prima le modifiche proposte e i possibili effetti sui servizi.

sudo apt update && sudo apt upgrade

&& esegue la seconda parte solo se la prima termina con successo. La guida agli operatori di concatenazione di Bash approfondisce queste condizioni.

I due lati di una pipe rimangono distinti

Una pipe collega l'uscita di un comando all'ingresso del successivo. Qui solo il primo comando viene avviato con l'identità di destinazione; grep mantiene quella dell'utente corrente.

sudo some-command | grep 'pattern'

some-command e pattern sono segnaposto da sostituire. Un filtro che legge dati dalla pipe spesso non ha bisogno di privilegi elevati: limita l'elevazione allo stadio che ne ha effettivamente necessità.

Avviare un'intera shell amplia i privilegi

Una forma come sudo sh -c 'command1 && command2' avvia entrambi i comandi dentro una shell con i privilegi di destinazione. Richiede attenzione a virgolette ed espansioni e permette operazioni più ampie. Per pochi comandi, invocazioni separate facilitano il controllo e la registrazione delle richieste.

Perché una redirezione può dare Permission denied

La shell apre il file prima di avviare sudo

Questo è un esempio del problema, non una procedura consigliata. La redirezione > viene preparata dalla shell corrente, che può non avere il permesso di aprire il file protetto. Se l'apertura fallisce, sudo non viene neppure avviato.

sudo echo 'value' > /etc/example.conf

Se invece il file è scrivibile dall'utente, > può troncarlo prima che sudo esegua il comando. Non usare un file di configurazione reale per provare questo comportamento.

Elevare solo la scrittura necessaria con tee

Per scrivere una breve riga, passa i dati a sudo tee. Qui è tee, avviato con l'identità autorizzata, ad aprire il file. /etc/example.conf è un percorso dimostrativo: sostituiscilo solo dopo aver verificato destinazione, contenuto e copia di ripristino.

printf '%s\n' 'value' | sudo tee /etc/example.conf > /dev/null

Senza -a, tee sovrascrive il file. Con -a aggiunge in coda; ripetere l'esempio aggiungerebbe altre righe. La redirezione a /dev/null nasconde la copia dei dati sullo standard output, non gli eventuali errori.

printf '%s\n' 'value' | sudo tee -a /etc/example.conf > /dev/null

Usare sudoedit per modifiche a più righe

sudoedit prepara una copia temporanea, la fa modificare dall'editor con i privilegi dell'utente invocante e poi riporta le modifiche nel file originale, se autorizzato.

sudoedit /etc/example.conf

Questo evita di eseguire l'intero editor come root. I controlli su collegamenti simbolici e directory scrivibili dipendono dall'implementazione, dalla versione e dalla politica. Il flusso di modifica non garantisce che il nuovo contenuto sia corretto: conserva una copia e verifica la configurazione con gli strumenti del servizio prima di applicarla. Per i file sudoers usa visudo, che ne controlla la sintassi.

Shell amministrativa: sudo -i e sudo -s

In una shell amministrativa, i comandi successivi non hanno bisogno del prefisso sudo. Controlla l'identità con id e la directory con pwd: l'aspetto del prompt non è una prova dell'identità. Per una o due operazioni preferisci invocazioni singole; quando hai finito, termina la shell con exit e verifica di essere tornato alla sessione prevista.

Modificare sudoers con visudo

Perché non modificarlo direttamente

Un errore in /etc/sudoers può impedire l'uso di sudo. visudo blocca il file contro modifiche concorrenti e controlla validità e sintassi prima di installare la nuova versione.

sudo visudo

Se il controllo segnala errori, correggili o abbandona la modifica: non forzare il salvataggio di una configurazione non valida. Il manuale di visudo descrive le opzioni e i controlli.

Separare le regole in sudoers.d

Per dividere le regole per ruolo, puoi usare un file dedicato sotto /etc/sudoers.d/. Prima controlla che il file principale includa effettivamente quella directory, normalmente tramite @includedir, e conserva una copia della configurazione valida.

sudo visudo -f /etc/sudoers.d/service-maintenance

Con @includedir, sudoers ignora i nomi contenenti un punto o terminanti con una tilde. Un nome come service-maintenance evita questi casi. Non aggiungere automaticamente un'estensione .conf e controlla proprietà e permessi secondo la distribuzione.

Controllare l'intera configurazione

Dopo la modifica, controlla il file principale e gli inclusi. Il controllo di un singolo frammento con -f può non rilevare conflitti con definizioni presenti altrove.

sudo visudo -c

Un controllo riuscito conferma la validità sintattica, non la sicurezza dei privilegi concessi. Mantieni aperta una sessione amministrativa separata finché non hai verificato la nuova politica con l'utente interessato: consulta sudo -l e prova soltanto operazioni autorizzate, incluse richieste che devono essere negate. Se qualcosa non funziona, usa la sessione mantenuta aperta e visudo per ripristinare la configurazione valida, quindi ripeti i controlli.

Struttura di una regola sudoers

Lo schema seguente è concettuale: i nomi dei campi non costituiscono una regola pronta da applicare. Tag e altri elementi possono essere facoltativi.

user host=(runuser:rungroup) tag: command

Questo frammento autorizza deploy a richiedere come root il riavvio e il controllo di attività di webapp.service. Presuppone che quel servizio esista e che systemctl si trovi nel percorso indicato; non è una regola da installare senza una valutazione del sistema.

deploy ALL=(root) /usr/bin/systemctl restart webapp.service, /usr/bin/systemctl is-active webapp.service

ALL nella posizione dell'host indica tutti gli host su cui questa politica è applicata, non l'esecuzione remota. Verifica il percorso con command -v systemctl. Il riavvio esegue indirettamente il codice del servizio: se deploy può modificare l'unità, i drop-in, gli eseguibili avviati o configurazioni che ne controllano l'esecuzione, la regola può consentire molto più del solo riavvio previsto. Proteggi anche questa catena di file e directory.

Progettare sudoers con privilegi minimi

Limitare ALL e NOPASSWD

Una regola come ALL=(ALL) NOPASSWD: ALL concede privilegi amministrativi molto ampi senza richiesta di password. Per l'automazione, definisci account dedicato, comandi e argomenti necessari, accesso ai segreti e registrazione delle richieste. Disabilitare la richiesta di password non restringe da solo ciò che un comando può fare.

Valutare le funzioni che possono avviare una shell

Editor, pager e programmi capaci di avviare processi, caricare plugin o scrivere file arbitrari possono offrire una via verso una shell amministrativa. Il nome del programma non basta a valutarlo: considera funzioni, parametri, variabili d'ambiente e file di configurazione che l'utente può controllare.

Fissare percorsi e argomenti

Indica il percorso assoluto dell'eseguibile e, dove possibile, i parametri esatti. Caratteri jolly e regole di negazione possono avere effetti inattesi; anche la loro interpretazione varia tra sudo originale e sudo-rs. Una concessione molto ampia seguita da poche esclusioni non è una base affidabile per limitare un amministratore.

Registrare e riesaminare le concessioni

Annota richiedente, revisore, motivazione e condizioni di scadenza. Rimuovi account e regole inutilizzati e confronta periodicamente i privilegi elencati da sudo -l con le necessità e i registri delle operazioni effettive.

Variabili d'ambiente e percorsi diversi

L'ambiente non viene necessariamente copiato

La politica può rimuovere variabili o creare un ambiente limitato. PATH, HOME, proxy e impostazioni della lingua possono differire da quelli della shell abituale. In sudoers, impostazioni come env_reset e secure_path influenzano questo comportamento.

sudo env

Se autorizzato, l'esempio permette di confrontare l'ambiente di destinazione con l'uscita di env dell'utente normale. Le variabili possono contenere token e altri segreti: esamina l'uscita localmente ed elimina i dati sensibili prima di condividerla. Un errore command not found può dipendere da un percorso diverso, ma anche da un programma assente.

Non usare -E come soluzione universale

In sudo originale, -E chiede alla politica di conservare l'ambiente invocante: la richiesta può essere respinta e non garantisce la conservazione di ogni variabile. Percorsi, proxy e impostazioni dei programmi possono cambiare il comportamento di un processo privilegiato. È preferibile autorizzare esplicitamente solo le variabili necessarie; sudo-rs non supporta questa opzione.

Usare sudo nell'automazione

Evitare l'attesa di una password con -n

Un processo automatico non deve restare in attesa di input interattivo. -n evita le richieste di input di sudo e fallisce se occorre chiedere una password; non concede privilegi aggiuntivi e non impone un limite di durata al comando avviato.

sudo -n /usr/bin/systemctl restart webapp.service

Il servizio e il percorso devono corrispondere al sistema e alla regola autorizzata. Controlla codice di uscita e registri per distinguere un rifiuto di sudo da un problema del servizio. Non incorporare password negli script o nelle righe di comando: potrebbero comparire in cronologia, registri o elenchi dei processi.

Concedere l'esecuzione non interattiva solo dove serve

Se l'esecuzione senza intervento è indispensabile, limita l'account dedicato ai comandi e agli argomenti previsti. L'account non deve poter modificare gli eseguibili né le impostazioni che ne determinano il comportamento. In base al compito, valuta anche API dedicate, servizi systemd o programmi di supporto con interfacce ristrette.

Errori comuni e controlli utili

Principi di sicurezza nell'uso di sudo

• Prima di eseguire comandi copiati, controlla opzioni, espansioni e percorsi di destinazione.
• Per rimozioni, dischi, partizioni, firewall e account, verifica prima l'impatto e la possibilità di ripristino.
• Non lasciare aperta una shell amministrativa per una singola operazione.
• Non inserire indiscriminatamente password, token o chiavi private in comandi, script o variabili d'ambiente.
• Non concedere privilegi a script o eseguibili modificabili dall'utente autorizzato.
• Controlla dove sono conservati i registri di sudo e per quanto tempo; per ambienti critici valuta raccolta centralizzata e registrazione di input e output.

La registrazione tradizionale dell'invocazione non equivale alla registrazione di ogni comando eseguito dentro sudo sh o tramite una funzione di avvio della shell. La registrazione di input e output, quando disponibile e configurata, è una funzione separata da valutare anche per la possibile presenza di dati sensibili.

Domande frequenti

sudo esegue sempre come root?

No. Root è normalmente la destinazione predefinita di un comando senza -u, ma la politica può cambiarla e -u consente di richiedere un altro account autorizzato. Inoltre, in sudo originale, usare -g senza -u mantiene l'utente invocante e cambia il gruppo di destinazione.

Perché sudo non chiede la password?

Può essere ancora valida una precedente autenticazione oppure può applicarsi una regola NOPASSWD. Consulta sudo -l per la politica. sudo -k invalida la cache della sessione, ma non cambia una regola che esenta dall'autenticazione: non garantisce quindi una richiesta di password al prossimo comando.

Perché sudo cd non cambia la directory corrente?

cd è un comando interno della shell e deve modificare la shell corrente. Un processo figlio non può cambiare la directory del processo padre; inoltre sudo normalmente richiede un eseguibile esterno. Per eseguire un comando in una directory precisa, verifica un'opzione del comando oppure, dove supportata e consentita dalla politica, sudo -D: riguarda la directory del nuovo comando, non quella della shell chiamante.

Posso modificare sudoers con un editor normale?

Usa l'editor attraverso visudo, che aggiunge blocco e controllo della sintassi. Per un frammento puoi usare sudo visudo -f /etc/sudoers.d/filename; dopo la modifica controlla anche l'intera configurazione con sudo visudo -c. Per sudoers, sudoedit da solo non sostituisce questi controlli.

Riepilogo

Per una singola operazione usa sudo command; per un altro account usa sudo -u user command. Controlla le autorizzazioni con -l, rinnova l'autenticazione con -v e invalida la cache con -k tenendo distinta la cache dalle regole di autorizzazione.

Modifica sudoers con visudo e usa sudoedit per i normali file di configurazione quando è consentito. Percorsi assoluti, argomenti definiti e protezione dei file eseguiti aiutano a limitare i privilegi. La raccolta dei comandi Linux di uso comune offre riferimenti per le altre operazioni amministrative.