Come noto l'accesso al DBMS MySQL necessita di autenticazione. I dati archiviati possono essere anche importanti quindi non è il renderli manipolarli da chiunque. Questo vuol dire che ad ogni utente autorizzato alla gestione dei database potranno essere associate una "username" e una "password" indispensabili per poter passare alla fase successiva al login, quella in cui il server MySQL rimane in attesa delle interrogazioni.
L'identità dell'utilizzatore si basa su due parametri: il nome utente (username) e l'host, nome della macchina su cui è in esecuzione il DBMS. La procedura di login è fondata invece sul database denominato "mysql" che contiene la tabella "user" con il compito di archiviare in tre colonne: host, user e password, cioè i dati di accesso dei diversi utilizzatori. L'accesso al DBMS sarà quindi consentito solo nel caso in cui vi sia una corrispondenza tra le informazioni contenute in uno dei records presenti in tabella e i dati immessi per l'autenticazione.
Valori consentiti per l'host
I valori consentiti per il campo host della tabella "user" sono in genere un comune hostname, un numero IP o semplicemente localhost se lavoriamo in locale. Nella definizione di un host vengono comunque accettati alcuni caratteri speciali come il simbolo percentuale ("%") e l'underscore ("_"); questi ultimi vengono utilizzati per facilitare operazioni di ricerca all'interno delle stringhe con un procedura omologa a quella dell'operatore SQL LIKE, per cui "%" indicherà qualsiasi gruppo di caratteri, mentre "_" indicherà la corrispondenza ad un solo carattere.
Nel caso in cui l'host sia definito tramite l'indicazione di un numero IP è possibile stabilire anche una netmask corrispondente al range di indirizzi da cui potrà essere effettuato l'accesso. Consideriamo un'autorizzazione formulata nel modo seguente:
GRANT ALL PRIVILEGES ON db.* TO claudio@'192.xx.xxx.0/255.255.255.0';
L'utente definito nell'istruzione avrà la possibilità di accedere a MySQL da qualsiasi terminale dotato di numero IP in grado di soddisfare la seguente condizione:
client_ip & netmask = host_ip
Che nel caso specifico sarà espressa in questo modo:
client_ip & 255.255.255.0 = 192.xx.xxx.0
Ciò significa avranno accesso al DBMS tutti i client il cui IP sarà ricompreso all'interno di un range che va dal "192.xx.xxx.0" al "192.xx.xxx.255."
L'utilizzo della netmask nella definizione degli host è previsto soltanto per indirizzi a 8, 16, 24 e 32 bit, quindi a partire dal numero minimo di bit potranno essere presi in considerazione solo gli indirizzi ottenuti sommando la cifra 8 al valore minimo precedente (8+8=16, 16+8=24..).
Ad esempio:
- 192.0.0.0/255.0.0.0: ricomprende qualsiasi indirizzo iniziante per 192;
- 192.168.0.0/255.255.0.0: ricomprende qualsiasi indirizzo iniziante per 192.168;
- 192.168.1.0/255.255.255.0: ricomprende qualsiasi indirizzo iniziante per 192.168.1;
- 192.168.1.1: prevede soltanto l'indirizzo IP specificato.
Valori superiori, inferiori o intermedi di bit non saranno accettati.
L' host può anche non essere specificato, in questo caso verrà considerato dal DBMS come omologo al carattere "%". L'utilizzo del simbolo percentuale nella definizione degli host pone alcuni problemi inerenti al tema della sicurezza. Un host specificato in questo modo:
192.xxx.xxx.%
potrebbe essere sfruttato per far sì che un utente malintenzionato riesca ad infiltrarsi nell'accesso al server MySQL digitando un host simile al seguente:
192.xxx.xxx.nome.it
Prevedendo un'evenienza del genere, MySQL è in grado di non consentire ricerche tramite wildcards sulla base di host contenenti caratteri alfabetici o punteggiatura, sarà quindi possibile effettuare operazioni di corrispondenza tramite "%" soltanto su IP di tipo numerico.
Gestione Password e User
Il discorso riguardante la gestione delle parole chiave nella tabella user di MySQL è abbastanza semplice. Anche la password relativa agli utenti può non essere indicata lasciando vuoto il valore del campo corrispondente. In questo caso il relativo utente avrà accesso al DBMS e al suo contenuto senza ulteriori controlli, per lui non avverrà alcuna ricerca relativamente alla parola chiave di accesso.
Nel caso in cui la password di un utente sia invece definita, quest'ultima verrà salvata in tabella dopo aver subito un processo di criptaggio da parte di MySQL eseguito tramite la funzione PASSWORD(). L'utente potrà continuare ad utilizzare per gli accessi la sua parola chiave non criptata, il DBMS la convertirà in modo da poter effettuare un confronto con i dati presenti in tabella. Ciò vuol dire che la "vera" password per l'autenticazione è quella criptata, l'unica che MySQL considera valida, ma per l'utente non sarà necessario conoscerla.
Più complesso è il discorso riguardante i nomi degli utenti. Infatti, sempre rimanendo in tema di sicurezza, è bene sottolineare che il campo user della tabella omonima non permette ricerche tramite caratteri speciali. È invece possibile non specificare il nome dell'utente in accesso, in questo caso esso verrà semplicemente considerato come un anonimo.
All'interno della tabella sono possibili numerose combinazioni tra host e nomi utenti:
- È possibile definire sia l'host che l'user completi, in questo modo saranno consentite connessioni soltanto nel caso in cui entrambi i valori siano correttamente specificati.
- È possibile indicare l'host ma non la u ser, ciò vuol dire che qualsiasi utente potrà avere accesso con l'unico vincolo di connettersi dall'host predefinito.
- Si può utilizzare il carattere speciale "%" per l'host e indicare un nome preciso per l'utente, in questo caso chiunque si presenti sotto quel nome avrà accesso indipendente dall'host di provenienza.
- È consentito utilizzare "%" e non specificare alcun nome utente, quindi chiunque avrà accesso indipendentemente da chi sia e da quale host si connetta.
- Il carattere "%" potrà essere posto all'inizio di un nome di host (ad esempio: %.host.it) e ad esso potrà essere associata una determinata username, se quest'ultima è corretta e così pure la parte dell'host successiva alla wildcard, allora sarà consentita la connessione.
- "%" potrà essere utilizzato in sostituzione dell'estensione presente nell'host (ad esempio nome.host.% al posto di ".it" o ".com" etc.), se associato ad una User l'accesso alla connessione col DBMS avverrà indipendentemente dal tipo di estensione reale.
Seguono poi i casi relativi agli indirizzi IP:
- Specificando un determinato IP e una determinata username l'accesso sarà possibile soltanto quando esse vengano indicate correttamente.
- L'utilizzo del carattere "%" nell'IP consentirà l'accesso all'utente specificato se proveniente da un client con IP compreso tra i numeri che soddisfano il confronto.
- Sarà possibile specificare una netmask per stabilire un intervallo di IP valido come spiegato in precedenza.
Come MySQL gestisce le procedure di accesso
Gli elenchi proposti suggeriscono un gran numero di combinazioni possibili, la ricerca di valori per la connessione potrebbe riguardare ben più di un unico record presente in tabella. Esistono a questo proposito delle semplici ma efficaci regole utilizzate da MySQL per decidere a quale record fa riferimento una determinata richiesta di accesso:
- Vengono letti tutti i records ed estratti quelli corrispondenti ai dati di autenticazione immessi.
- Le righe ordinate per host e poi per user.
- Viene preso in considerazione il primo record considerato valido.
Facciamo un esempio; supponiamo di avere una tabella user contenente i seguenti dati:
+-----------+----------+ | host | User | +-----------+----------+ | % | root | | % | claudio | | n.host.it | root | | n.host.it | | +-----------+----------+
Nel momento in cui essa viene letta è anche ordinata in modo che il record più specifico passi in prima posizione, quindi i record in cui vengono utilizzate le wildcard devono essere accodati. I valori di host sono letti per primi e sono considerati più specifici quelli numerici o letterali in sfavore di quelli che contengono caratteri per il matching; nel caso in cui il DBMS dovesse scegliere tra due record con valore host di specificità equivalente, si passerà ad un ulteriore ordinamento per user accodando quelli in cui il nome utente non è definito:
+-----------+----------+ | host | User | +-----------+----------+ | n.host.it | root | | n.host.it | | | % | claudio | | % | root | +-----------+----------+
Nel momento in cui un terminale effettuerà una richiesta di accesso tramite autenticazione, MySQL controlla innanzitutto la corrispondenza con il primo record ottenuto dall'ordinamento dei dati che sarà sempre il più specifico tra quelli contenuti in tabella.
Il fatto che il primo termine di confronto sia sempre il valore di host ha un'implicazione molto importante. Prendiamo per esempio una tabella user di questo tipo:
+----------------+----------+ | host | User | +----------------+----------+ | % | claudio | | n.host.it | | +----------------+----------+
In seguito all'ordinamento effettuato per rispondere alla richiesta di accesso avremo questo nuovo ordine:
+----------------+----------+ | host | User | +----------------+----------+ | n.host.it | | | % | claudio | +----------------+----------+
Dato che per il DBMS sarà sufficiente controllare il primo record per autenticare l'utente, questo verrà riconosciuto come anonimo anche se dovesse inserire la sua user; infatti, loggandosi con un host corretto il confronto si fermerebbe al primo record che prevede di accettare connessioni indipendentemente dall'user che le richiede.
Basterà utilizzare il comando CURRENT_USER() per ottenere una controprova di quanto appena affermato:
mysql> SELECT CURRENT_USER();
