5.2. Login sul sistema

Con il termine login sul sistema, intendiamo una azione di verifica di credenziali, impostazione dei diritti di accesso e permesso agli utenti di procedere con la loro sessione sul computer. Come esattamente apparirà quella sessione, dipende dal tipo di servizio realmente richiesto e dal tipo del software client dell'utente.

In generale, gli utenti sono forniti di account individuali nei quali possono effettuare il login. Ci sono due gruppi principali di account:

5.2.1. Login in console

Probabilmente il metodo più diretto per fare il login sul sistema è quello di sedersi fra la tastiera e la sedia, e fare il login al prompt della console del sistema locale. In generale, una variante del programma getty sarà in attesa sulle console per ricevere le informazioni di autenticazione. /sbin/getty predefinito in Debian, viene avviato da /sbin/init. /sbin/init, a sua volta, prende la sua configurazione dal file già menzionato /etc/inittab. Sono disponibili molte varianti di getty (si provi ad eseguire apt-cache search --names-only getty ad esempio) ma "getty" è stato anche scelto come una sorta di nome generico per l'intera categoria.

È interessante notare che getty legge il nome utente e la password iniziale, e termina il suo compito passando il controllo al programma /bin/login. La questione è tuttavia, cosa succede se si digita un nome utente o una password errati (o non ci si autentica con successo per qualche altra ragione)? Siccome getty è fuori dal gioco, il programma login medesimo fornirà un nuovo prompt che tuttavia somiglierà esattamente a quello originale di getty. Solo se si fallisce l'autenticazione per un paio di volte, o si termina la propria sessione, /bin/login si chiuderà e, (grazie ad init), /sbin/getty sarà rigenerato ("avviato nuovamente") per attendere nuovi login.

NotaDeterminare chi c'è dietro il prompt di login: /sbin/getty o /bin/login?
 

Se si preme Invio ad un prompt di login su una console vuota e il sistema ne fornisce immediatamente un altro, si sta contattando il sistema getty. Altrimenti, se per esempio c'è un attimo di attesa prima, si sta comunicando con /bin/login.

5.2.2. La shell di "login"

Supponendo che si sia gestita l'autenticazione con successo e che i programmi getty o login abbiano dato il permesso di accesso, cosa succede adesso?

Bene, prima di rispondere a questa domanda, si ha come prima cosa la necessità di prendere familiarità con le proprie voci nel file /etc/passwd. Ci sono diversi metodi per recuperarle: si può aprire il file con un editor di testo e cercare il proprio nome utente, si può avviare grep $USER /etc/passwd e si può avviare getent passwd $USER. L'ultima variante è suggerita dato che può funzionare con schemi di autenticazione utente arbitrari. Una voce di esempio potrebbe essere simile a questa:

$ getent passwd $USER   
mario:x:1000:1000:Mario,,,:/home/mario:/bin/bash
I campi 6, 7 e 8 specificano le informazioni utente GECOS, la propria directory home e la shell predefinita.

Generalmente, dopo che si è stati autenticati, il software fornisce la shell indicata e sposta sulla propria directory home. Siccome Unix e gli utenti spesso configurano i propri ambienti, sono disponibili file globali di impostazione, /etc/profile e /etc/environment (il primo è uno script eseguibile, l'altro è una collezione di coppie CHIAVE=VALORE e non esiste in modo predefinito). La shell bash legge anche /etc/bash.bashrc e possibilmente altri file /etc/bash* (se configurata per includerli). Dopo avere onorato i file di configurazione validi per tutto il sistema, la shell legge i loro corrispondenti dotfile specifici dell'utente all'avvio. Nuovamente, in caso della shell bash sono ~/.bash_profile o ~/.bashrc.

A questo punto è importante imparare la differenza tra shell di login e shell non di login. Le shell di login sono il caso speciale nel quale gli utenti sono dall'altra parte di una connessione (invece di un file script batch o di un altro programma) e utilizzano un terminale in modo interattivo. Quando si fa il login sul sistema utilizzando telnet o SSH, si ottiene una shell di login. Le shell di login leggono ~/.bash_profile, che dovrebbe contenere le impostazioni importanti per il lavoro interattivo (alias dei comandi, prompt, display, eccetera). Tutte le altre shell sono shell "non login".

L'utente root non legge il file /etc/profile e, per convenzione Debian, il suo dotfile è ~/.profile invece di ~/.bash_profile (ma questo non è obbligatorio, se ~/.bash_profile fosse presente, avrebbe la precedenza).

Possimo ricordare che il "linguaggio di shell" è stato standardizzato da POSIX, perciò ogni file di shell che non sia specifico di bash dovrebbe essere libero da qualsiasi "bashismo". E infatti, c'è un forte movimento presente in Debian per liberare gli script del manutentore da tutti i costrutti non conformi a POSIX. Seguendo l'analogia, il file ~/.profile del proprio utente root dovrebbe essere scritto tenendo a mente lo standard POSIX sh. Ksh (la shell Korn) è molto conforme a POSIX e si può utilizzarla per scrivere script conformi a POSIX; si veda la pagina Korn Shell (ksh) Programming per informazioni aggiuntive.

È anche utile notare che la shell non utilizza nessuna tecnica segreta per leggere i dotfile; essa li valuta nel contesto del processo in corso utilizzando il comando source o . (un punto).

Quando questi compiti di "avvio" sono stati realizzati, il sistema mostra il prompt di comando ed è pronto ad accettare comandi.

5.2.3. Impostazione del login all'account

Siccome la maggior parte degli account sulla propria macchina saranno utilizzati in locale, per conto proprio, non c'è ragione per permettere alle persone di fare il login da remoto, giusto? Si potrebbe essere interessati a permettere l'accesso ai propri amici, ma ciò è cosa differente, si fornirebbe loro un proprio account personale e si prenderebbero alcune precauzioni di base prima di aprire il sistema al mondo.

Tutto questo è difficile da spiegare adesso, perché tocca già quel magico mondo della sicurezza di Unix, che è così ampio e diversificato che qualsiasi commento su di esso potrebbe distrarci notevolmente, anche se ignorassimo il pensiero "intuitivo" e ci limitassimo alla definizione formale.

Così, ad ogni modo, dato che abbiamo stabilito che non vogliamo che persone effettuino il login remoto, editare il file /etc/security/access.conf, leggere il breve testo introduttivo incluso nel file e aggiungere qualcosa di simile a questo alla fine:

-:root mario dante:ALL EXCEPT LOCAL

Quanto sopra impedirebbe l'accesso a root, mario o dante, eccetto che da localhost. Le impostazioni nel file /etc/security/access.conf vengono onorate perché il sottosistema PAM può essere configurato per leggerle, così come spiegheremo nella prossima sezione.