Sudo/it

Il comando fornisce una via semplice e sicura per configurare la scalata dei privilegi, permettendo, ad esempio, agli utenti di eseguire certi (o tutti) comandi come root o come un altro utente differente, eventualmente senza fornire alcuna password.

Quando si vuole che altri utenti possano eseguire certe azioni amministrative sul proprio sistema senza concedere il totale accesso root, l'uso di  è la migliore opzione. Con sudo è possibile chi può fare e cosa può essere fatto. Questa guida offre una piccola introduzione a questo strumento.

Questo articolo intende essere una veloce introduzione a. Il pacchetto è molto più potente di quanto si descritto in questo documento. Infatti, ha funzionalità speciali per modificare file come differente utente, eseguire dall'interno di uno script (lanciato in background, leggere la password dallo standard-in in alternativa alla tastiera, ...), ecc.

Per favore leggi le pagine del manuale di e di  per avere maggiori informazioni.

Attività di log
Un vantaggio addizionale di è che può scrivere sul log ogni tentativo (con successo o senza successo) di eseguire una applicazione. Questo è molto utile se si vuole tenere traccia di chi fa un errore fatale che potrebbe richiedere 10 ore per la risoluzione.

Ottenimento dei permessi
Il pacchetto permette all'amministratore del sistema di ottenere i permessi di altri utenti per eseguire una o più applicazioni di cui solitamente non si hanno i diritti. Diversamente dall'uso del bit  su queste applicazioni,  dà un grana di controllo molto fine su chi può eseguire certi comandi e quando questo può essere fatto.

Con è possibile fare una chiara lista di chi può eseguire una certa applicazione. Mentre se si usasse il bit, ogni utente potrebbe essere autorizzato ad eseguire questa applicazione (oppure ogni utente di un certo gruppo, in base ai permessi usati). E' possibile (e probabilmente si dovrebbe) richiedere all'utente di fornire una password quando questo vuol eseguire un dato programma.

La configurazione di è gestita dal file. Questo file non dovrebbe essere mai modificato tramite o  o ogni altro editor. Quando si vuole alterare questo file, andrebbe usato il comando.

Questo strumento garantisce che non ci siano due amministratore che contemporaneamente stiano modificando questo file allo stesso momento, preserva i permessi del file ed esegue alcuni controlli sintattici per essere sicuro che non ci siano errori fatali nel file.

Sintassi di base
La parte più difficile di è la sintassi del file. La sintassi di base è simile alla seguente:

Questa sintassi dice a che l'utente, identificato da   e loggato nel sistema   può eseguire ogni comando elencato nella clausola   come utente root. Un esempio più aderente alla realtà rende questo più chiaro: permettere l'utente di eseguire il comando  se è loggato nel sistema localhost:

Il nome utente può essere anche sostituito con il nome del gruppo - in questo caso il nome del gruppo andrebbe prefissato con il segno. Per esempio, per permettere ad ogni utente nel gruppo di eseguire :

La linea può essere estesa per permettere molti comandi (invece di inserire una singola voce per ogni comando). Per esempio, per permettere allo stesso utente di non eseguire solo ma anche  e  come root:

E' possibile anche specificare una precisa riga di comando e non solo il tool stesso. Questo è utile per restringere l'uso di un certo tool ad uno specifico set di opzioni della riga di comando permette di usare wildcard stile shell (AKA meta o caratteri jolly) nei path name come negli argomenti dell righe di comando specificate all'interno del file sudoers. E' da notare come queste non siano espressioni regolari.

Let us put this to the test:

La password che richiede è la password dell'utente stesso. Questo è per rendere sicuro che altri utenti non possano abusare con intenti maliziosi di alcun terminale lasciato accidentalmente aperto.

Si dovrebbe sapere che non altera la variabile  : ogni comando indicato dopo  è trattato in aderenza al proprio ambiente. Se si vuole permettere all'utente di eseguire un tool in, questo deve fornire il path completo a :

Sintassi di base con LDAP
Le USE flag  e   sono entrambe necessarie per il supporto a LDAP.

Quando si usa LDAP, sudo leggerà la configurazione dea un Server LDAP. E' necessario quindi modificare due files.

E' necessario aggiungere la seguente voce a LDAP per Sudo.

Le configurazioni su un sudoers su LDAP sono simili a file con qualche differenza. Si legga in aggiunta Sudo con LDAP nel link seguente.

è un alias di tutte le possibili configurazioni.

A sample use of the  alias to allow any user to execute the  command if he is logged on locally is:

Another example is to allow the user to execute the  command as root, regardless of where he is logged in from:

More interesting is to define a set of users who can run software administrative applications (such as and ) on the system and a group of administrators who can change the password of any user, except root!

Esecuzione non-root
It is also possible to have a user run an application as a different, non-root user. This can be very interesting if you run applications as a different user (for instance for the web server) and want to allow certain users to perform administrative steps as that user (like killing zombie processes).

Inside you list the user(s) in between   and   before the command listing:

For instance, to allow to run the  tool as the  or  user:

With this set, the user can run to select the user he wants to run the application as:

You can set an alias for the user to run an application as using the  directive. Its use is identical to the other  directives we have seen before.

Passwords and default settings
By default, asks the user to identify himself using his own password. Once a password is entered, remembers it for 5 minutes, allowing the user to focus on his tasks and not repeatedly re-entering his password.

Of course, this behavior can be changed: you can set the  directive in  to change the default behavior for a user.

For instance, to change the default 5 minutes to 0 (never remember):

A setting of  would remember the password indefinitely (until the system reboots).

A different setting would be to require the password of the user that the command should be run as and not the users' personal password. This is accomplished using. In the following example we also set the number of retries (how many times the user can re-enter a password before fails) to   instead of the default 3:

Another interesting feature is to keep the  variable set so that you can execute graphical tools:

You can change dozens of default settings using the  directive. Fire up the manual page and search for.

If you however want to allow a user to run a certain set of commands without providing any password whatsoever, you need to start the commands with, like so:

Bash completion
Users that want bash completion with sudo need to run this once.

Zshell completion
Users that want zsh completion for sudo can set the following in and  respectively

With the above change, all commands in the, and  locations will be available to the shell for completion when the command is prefaced with 'sudo'.

Listing privileges
To inform yourself what your capabilities are, run :

If you have any command in that does not require you to enter a password, it will not require a password to list the entries either. Otherwise you might be asked for your password if it isn't remembered.

Prolonging password timeout
By default, if a user has entered their password to authenticate their self to, it is remembered for 5 minutes. If the user wants to prolong this period, he can run to reset the time stamp so that it will take another 5 minutes before  asks for the password again.

L'inverso è uccidere la stampa temporale usando.