Linux / Comando su: cambiare utente e shell di login

su esegue una shell o un comando con l’identità di un altro utente e dei relativi gruppi. Senza un nome utente, tenta normalmente di avviare una shell come root; con su --login user prepara un ambiente simile al login dell’account di destinazione, se l’autenticazione e la politica lo consentono.

Un semplice su user mantiene la directory di lavoro corrente e parte dell'ambiente, che può mescolarsi con le impostazioni di un altro utente. Per un cambio di account interattivo, di solito si utilizza su --login user, e se lo scopo è solo eseguire un singolo comando amministrativo, è meglio considerare prima se sudo basato su regole di autorizzazione sia più appropriato.

Cos'è il comando su?

Il nome richiama la sostituzione dell’identità utente e dei gruppi: su avvia il processo nel contesto dell’account di destinazione. Se ometti il nome, la destinazione predefinita è root.

L’implementazione di util-linux usa PAM, Pluggable Authentication Modules, il sistema modulare di autenticazione di Linux, per autenticazione e gestione di account e sessioni. Password richiesta, eventuali restrizioni a determinati gruppi e registrazione dei tentativi dipendono dalla distribuzione e dalla configurazione PAM.

Questa guida riguarda util-linux: altre implementazioni, comprese quelle fornite da pacchetti diversi, possono avere opzioni e comportamenti differenti. Consulta la pagina del manuale ufficiale di su di util-linux.

Sintassi di base e cambio account

La sintassi seguente è uno schema: sostituisci options, user e arguments con valori reali e non copiare le parentesi quadre.

su [options] [-] [user [arguments...]]

Se non viene specificato alcun utente, tenta di passare all'account root.

su

Da un account normale viene generalmente richiesta la password dell’account root di destinazione, non quella dell’utente invocante. Il blocco della password di root o una restrizione PAM può impedire questa autenticazione; eventuali metodi alternativi dipendono dalla politica del sistema.

Per scegliere un altro account, indicane il nome. Gli esempi con deploy presuppongono che tale account esista e che tu sia autorizzato ad accedervi.

su deploy

Per tornare alla shell di partenza, esegui exit nella shell aperta da su oppure invia la fine dell’input con Ctrl+D. Se hai aperto più shell annidate, ogni uscita ne chiude una: verifica di essere tornato alla sessione prevista.

exit

La differenza tra su e su --login

Il manuale di util-linux raccomanda --login per ridurre i problemi dovuti a un ambiente misto. La forma breve - ha lo stesso significato: le due righe seguenti sono alternative. Eseguine una sola e usa exit prima di provare l’altra.

su --login deploy
su - deploy

Modifiche nell'ambiente della shell di login

Pulisce la maggior parte delle variabili d'ambiente esistenti

su --login di util-linux cancella l'ambiente esistente eccetto per TERM, COLORTERM, NO_COLOR e le variabili esplicitamente permesse. In seguito inizializza HOME, SHELL, USER, LOGNAME e PATH in base all’account di destinazione, secondo il manuale corrente. Versioni meno recenti possono differire nelle variabili conservate.

L'ambiente finale può anche riflettere valori aggiunti o modificati dai moduli PAM, quindi non si dovrebbe presumere che sia esattamente lo stesso tra le distribuzioni.

Spostarsi nella directory home dell'utente di destinazione

--login tenta di passare alla home dell’account e avvia una shell di login. Controlla eventuali avvisi su home assente o non accessibile; dopo il passaggio, verifica identità, HOME e directory effettiva con questi comandi.

id
printf '%s\n' "$HOME"
pwd

Modifica dei file di inizializzazione della shell

Una shell di login legge i file di avvio previsti dalla propria implementazione. Bash legge /etc/profile, se esiste, poi il primo file esistente e leggibile tra ~/.bash_profile, ~/.bash_login e ~/.profile. Non legge necessariamente tutti e tre. Le impostazioni dell’account possono a loro volta caricare altri file; il manuale di Bash descrive le regole di avvio.

Opzioni di su più usate

Eseguire un singolo comando come un altro utente

Eseguire un comando con -c

Se non hai bisogno di rimanere in una shell interattiva, puoi passare comandi alla shell dell'utente di destinazione con -c.

su -c 'id' deploy

Quando il comando termina, anche su termina e il controllo torna alla shell chiamante. La stringa dopo -c viene interpretata dalla shell di destinazione: le virgolette singole dell’esempio impediscono espansioni nella shell chiamante, ma il contenuto viene poi analizzato dalla shell avviata. Controlla quindi dove avvengono espansioni e redirezioni.

Esecuzione di comandi in un ambiente di login

Per usare l’ambiente di login e la home dell’account, combina --login e -c. L’uscita prevista è la directory effettiva seguita dall’identità dell’account deploy.

su --login -c 'pwd; id' deploy

I due comandi separati da ; vengono eseguiti nella shell di destinazione, anche se il primo fallisce. Lo stato finale riflette normalmente l’ultimo comando: un id riuscito non dimostra che pwd sia riuscito. Non concatenare input esterno non controllato a una stringa eseguita con privilegi elevati: potrebbe diventare codice della shell.

Controllare lo stato di uscita dei comandi

Normalmente su restituisce lo stato del comando eseguito; se questo viene terminato da un segnale, restituisce 128 più il numero del segnale. Gli errori generati da su prima o durante l’avvio possono essere 1 per un errore generale precedente all’esecuzione, 126 se il comando non è eseguibile e 127 se non è trovato. Anche la shell o il programma avviato possono restituire questi numeri: leggi anche il messaggio di errore.

su -c '/usr/local/bin/check-job' deploy
status=$?
printf 'exit=%s\n' "$status"

/usr/local/bin/check-job è un percorso dimostrativo da sostituire con un programma esistente e autorizzato. Salva $? subito dopo su, prima di altri comandi che lo sovrascrivano; exit=0 indica normalmente successo, mentre gli altri valori vanno interpretati secondo il programma e i messaggi prodotti.

Gestione delle shell e degli account a privilegi limitati

Shell predefinita dell'utente di destinazione

Senza una scelta esplicita, viene normalmente usata la shell registrata per l’account, con ripiego su /bin/sh se non è definita. Un’eccezione è --preserve-environment, che può selezionare la shell indicata nella variabile SHELL. Consulta l’account con getent, senza modificare passwd: l’uscita comprende anche home e shell.

getent passwd deploy

Specificare la shell con -s

Puoi specificare una shell diversa con -s.

su -s /bin/sh -c 'id' deploy

Per su, una shell non elencata in /etc/shells è considerata limitata: in questo caso -s e la variabile SHELL vengono ignorati se il chiamante non è root. La possibilità tecnica di un amministratore non rende appropriato aprire un accesso interattivo a un account di servizio.

Rispettare lo scopo degli account di servizio

Gli account con nologin o false impostati come shell probabilmente non sono destinati a login interattivi. Se hai bisogno di lavorare con un tale account, esegui solo il comando necessario e verifica prima se ci sono comandi di gestione forniti dal servizio o se sono disponibili funzionalità di systemd.

Usa con cautela la conservazione delle variabili d'ambiente

Significato di --preserve-environment

L'opzione --preserve-environment conserva l'ambiente attuale senza reimpostare HOME, SHELL, USER o LOGNAME. Viene ignorata se specificata con --login.

su --preserve-environment deploy

Conservare HOME e altre impostazioni del chiamante mentre il processo opera come un altro utente può far usare file di configurazione inattesi o creare file con un proprietario diverso. Usalo solo se tale conservazione è intenzionale. PAM può ancora modificare l’ambiente finale: non è una copia immutabile dell’ambiente originario.

Consentire solo le variabili necessarie

In util-linux, puoi preservare solo le variabili necessarie combinando --login e --whitelist-environment.

su --login --whitelist-environment=LANG,LC_ALL deploy

HOME, SHELL, USER, LOGNAME e PATH sono esclusi dalla whitelist. Anche le variabili della locale, cioè lingua e convenzioni regionali, influenzano i programmi: conserva solo quelle necessarie e controlla che i valori siano validi per il sistema.

Differenza tra su e sudo

Autenticazione e registrazione dipendono dalle politiche effettive: la tabella descrive il caso tipico. Per una singola operazione amministrativa, sudo può evitare di dover conoscere la password dell’account di destinazione e permette regole per comando. Non richiede comunque di concedere una shell completa: vedi la guida a sudo, sudoers e visudo su Linux.

Perché non riesco a passare a root?

L'account root potrebbe essere bloccato

Alcune distribuzioni disabilitano il login con password per l'account root per impostazione predefinita e utilizzano l'amministrazione tramite sudo. In questo caso, inserire la password dell'utente corrente in su - non avrà successo.

Se l'utente ha privilegi sudo e la politica lo consente, è possibile aprire una shell root in stile login come segue, ma se sono necessari solo comandi individuali, è più sicuro usare sudo command piuttosto che una shell da amministratore.

sudo -i

PAM o le politiche di gruppo possono imporre restrizioni

La configurazione PAM, normalmente in /etc/pam.d/su e, per il login, in /etc/pam.d/su-l, può restringere i gruppi ammessi o richiedere ulteriori verifiche. Non indebolire arbitrariamente le impostazioni PAM per ottenere privilegi; invece, fornisci all'amministratore di sistema i compiti necessari e gli account di destinazione.

Potrebbero esserci problemi con lo stato dell'account di destinazione

Il cambio potrebbe fallire a causa della scadenza dell'account, del blocco, della directory home errata, della shell limitata o dei permessi dei file. Se sei un amministratore, verifica la causa con getent passwd user, strumenti di gestione degli account e log di autenticazione.

Quando root agisce come un altro utente

runuser potrebbe essere più adatto per l'automazione

Per gli script già eseguiti da root, il manuale di runuser descrive uno strumento che non richiede l’autenticazione con password, usa una configurazione PAM separata e non necessita del bit set-user-ID.

runuser -u backup -- /usr/local/bin/backup-job

backup e /usr/local/bin/backup-job devono essere un account e un programma reali previsti dalla procedura amministrativa. Con -u, runuser esegue direttamente il comando con gli argomenti successivi a --. Solo root può usarlo: non è un sostituto di sudo per ottenere privilegi da un account normale.

Quando valutare setpriv

Se hai semplicemente bisogno di cambiare gli ID utente/gruppo e gli attributi dei permessi per eseguire un programma e non è richiesta una sessione PAM, util-linux suggerisce anche setpriv come alternativa. Questo strumento gestisce direttamente i privilegi e gli attributi di sicurezza, quindi dovrebbe essere utilizzato solo dagli amministratori che comprendono esattamente le impostazioni di utente, gruppo, gruppo supplementare e capacità.

Separare la sessione con uno pseudoterminale

Separazione fornita da --pty

--pty crea uno pseudoterminale separato e su fa da intermediario per ingresso e uscita. È pensato soprattutto per l’uso interattivo: evita la condivisione diretta del terminale, che può consentire l’iniezione di input nella sessione originaria. Non isola filesystem, rete o privilegi come farebbe un ambiente separato.

su --pty --login deploy

Non è una sessione completa di login systemd

Una shell di login non equivale a una nuova sessione completa gestita da systemd-logind. Anche la nuova sessione di processi creata da su -c tramite setsid è un concetto distinto. Se servono servizi utente o confini di sessione gestiti da systemd, valuta strumenti come systemd-run o machinectl con modalità adatte al compito.

Precauzioni di sicurezza

• Non condividere la password di root o le password di altri utenti con più persone.
• Non inserire le password nella riga di comando, nella cronologia della shell, negli script o nelle pipe.
• Non mantenere una shell root aperta più a lungo del necessario; esegui exit subito dopo aver completato il lavoro.
• Subito dopo il cambio, controlla id, pwd e HOME per evitare confusione tra utenti e percorsi.
• Per i comandi da eseguire con privilegi elevati, prima rivedi le opzioni, i percorsi di destinazione e i risultati delle espansioni di caratteri jolly.
• Non dare per scontato che i log siano conservati; invece, verifica le impostazioni effettive e le politiche di conservazione di PAM, journal e dei log di autenticazione.

I comandi eseguiti dopo l'apertura di una shell root con su sono separati dai registri di autenticazione di su stesso. Se è richiesto il monitoraggio dei singoli comandi, dovresti progettarlo insieme al monitoraggio della shell, alla registrazione centralizzata o a metodi come sudo che forniscono politiche per singolo comando.

Problemi comuni e soluzioni

Domande frequenti

Quale password richiede su?

Generalmente, inserisci la password dell'utente di destinazione a cui vuoi passare. Se però su viene eseguito da root o PAM prevede un altro metodo, il comportamento può cambiare. È normale che i caratteri non vengano visualizzati sullo schermo durante l'inserimento della password.

Qual è la differenza tra su e su -?

Senza un nome utente, su tenta di avviare una shell root mantenendo la directory corrente e parte dell’ambiente. su - si sposta nella home dell'utente root e configura l'ambiente di login. In util-linux, la forma di login è raccomandata per ridurre i problemi di un ambiente misto.

Come verifico l’identità dopo il cambio con su?

id è utile per controllare insieme utenti e gruppi reali ed effettivi. Se hai bisogno solo di un semplice nome utente, puoi usare whoami, ma per controllare i gruppi supplementari, id fornisce più informazioni.

Va bene mettere la password di su nello script?

No. La password può essere esposta in file, informazioni dei processi o log. Se si automatizza come root, usa runuser solo per gli account e i comandi previsti dalla procedura, proteggendo anche gli script e i file che controllano l’esecuzione. Se è per l'elevazione dei privilegi come utente normale, progetta un modo che non incorpori la password, come utilizzare regole sudoers con privilegi minimi o un servizio dedicato per il compito.

Riepilogo

Per il cambio account interattivo generale, puoi usare su --login user, e per un singolo comando, su -c 'command' user. Un semplice su user può mescolare gli ambienti, quindi è bene controllare id, HOME e pwd dopo il cambio.

Se l'obiettivo è eseguire un solo comando root, sudo, che fornisce il controllo dei permessi per comando e l'auditing, può essere più appropriato. Quando si esegue come un altro utente nell'automazione root, considera runuser. Puoi anche controllare insieme gli strumenti di base correlati nella lista dei comandi comunemente usati in Linux.