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:
Account di sistema, account che sono registrati su un livello di sistema, abitualmente nei file /etc/passwd, /etc/groupe /etc/shadow. I file citati costituiscono lo schema tradizionale di Unix per l'autenticazione degli utenti, tuttavia alcune informazioni possono anche essere recuperate in vari database, per esempio nelle cosiddette directory che consistono di coppie chiave:valore e sono ottimizzate per accessi massicci in sola lettura (LDAP).
Gli account di sistema sono indipendenti dai servizi e profondamente radicati nella filosofia Unix. Uno dei loro valori chiave è la piena tracciabilità in termini di date e tempi di accesso, operazioni eseguite e risorse di sistema utilizzate. Esempi tipici sono gli account che si utilizzano per accedere a tutti i servizi telnet, SSH e FTP.
Questi account "reali" saranno il nostro interesse primario e ci riferiremo ad essi come account di sistema o semplicemente account.
Account virtuali, account che non sono registrati ad un livello di sistema, ed invece esistono in database di servizio specifici. Quei database possono essere basati su file o LDAP dietro le quinte, ma siccome le soluzioni di account virtuali sono popolari per la loro semplicità e impostazione ad-hoc (eccetto per poche implementazioni degne di nota), la maggior parte di essi al giorno d'oggi sembra esistere in database MySQL. Un esempio tipico di account virtuali in uso, sono i negozi sul web e le invenzioni cretine tipo e-mail sul web. Gli account virtuali sono diventati anche piuttosto popolari in impostazioni nelle quali gli utenti accedono alle proprie e-mail utilizzando protocolli opportuni, ma avendo solo "mailbox virtuali" sul server invece di account reali.
Come abbiamo ricordato, gli account virtuali sono per lo più "dipendenti dal servizio" ed è, mancando qualsiasi formalità sia nella fase progettuale che in quella di implementazione, intrinsecamente scomodo tenerne traccia. Invece di riutilizzare l'infrastruttura di sistema stabilita, le applicazioni devono gestire gli utenti virtuali a modo proprio. In aggiunta, invece di svolgere i compiti con i privilegi degli appropriati account di sistema, tali applicazioni girano con un singolo nome utente, complicando ulteriormente qualsiasi controllo di accesso accurato e le statistiche di sistema.
Gli account virtuali sono un completo disastro (eccetto, nuovamente, per alcuni importanti campi di utilizzo e di implementazione) e sono fioriti dal 1995 in avanti, il periodo che fu caratterizzato dall'avvento dei "personal computer" e dalla scomparsa di tutte le correttezze tecniche dal settore civile.
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.
 | Determinare 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/bashI 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.