Cuando intente conectar a un servidor MySQL, el servidor aceptará o rechazará la conexión basándose en su identidad y si usted puede identificar su identidad proporcionando la clave correcta. Si no es así, el servidor le denegará el acceso completamente. En caso contrario, el servidor acepta la conexión, y entra en el Estado 2, y espera peticiones.
Su identidad se basa en dos elementos de información:
- El nombre de máquina cliente (o ip) desde donde usted se conecta
- Su nombre de usuario MySQL
La comprobación de la identidad se realiza utilizando las tres columnas de la tabla
user
(Host
, User
, yPassword
). El servidor sólo acepta la conexión si las columnas Host
y User
de alguna de las tablas user
es coincidente con el nombre de máquina y usuario del cliente, y además el cliente proporciona la clave especificada en ese registro.
Los valores de
Host
en la tabla user
pueden ser especificados de las siguientes maneras:- Un valor de
Host
debe ser un nombre de máquina o un número IP, o'localhost'
para indicar la máquina local. - Puede utilizar los caracteres comodín '
%
' y '_
' en los valores de las columnasHost
. Estos tienen el mismo significado que en las operaciones de búsqueda de patrones realizadas mediante el operadorLIKE
. Por ejemplo, un valor deHost
igual a'%'
retorna cualquier nombre de máquina, así como un valor de'%.mysql.com'
retorna cualquier nombre de máquina en el dominiomysql.com
. - Para valores de
Host
especificados como números IP, puede especificar una máscara de red indicando cuantos bits de la dirección utilizar para el número de red. Por ejemplo:mysql> GRANT ALL PRIVILEGES ON db.*-> TO david@'192.58.197.0/255.255.255.0';Esto permite adavid
conectarse desde cualquier cliente que tenga un número IPclient_ip
para el que la siguiente condición sea cierta:client_ip & netmask = host_ip
Es decir, para la sentenciaGRANT
recientemente mostrada: That is, for theGRANT
statement just shown:client_ip & 255.255.255.0 = 192.58.197.0
Los números IP que satisfagan esta condición y pueden conectar al servidor MySQL son lo que están en el rango desde192.58.197.0
hasta192.58.197.255
. - Nota: La máscara de red solo puede ser utilizada para decirle al servidor que use 8, 16, 24 o 32 bits para la dirección, por ejemplo:192.0.0.0/255.0.0.0 (cualquier dirección de la red clase A 192)192.168.0.0/255.255.0.0 (cualquier dirección de la red clase B 192.168)192.168.1.0/255.255.255.0 (cualquier dirección de la red clase C 192.168.1)192.168.1.1 (solo esta IP específica)La siguiente máscara de red (28 bits) no funcionará:192.168.0.1/255.255.255.240
- Un valor vacío de
Host
en un registro de la tabladb
significa que los privilegios de dicho registro deben ser combinados con aquellos que se encuentren en el registro de la tablahost
que concuerde con el nombre del cliente. Los privilegios se combinan utilizando operaciones AND (intersección), no OR (union). Puede encontrar más información sobre la tablahost
en Sección 5.6.6, “Control de acceso, nivel 2: comprobación de solicitudes”.Un valor deHost
en blanco en las otras tablas grant lo mismo que'%'
.
Debido a que puede usar comodines en los valores IP de la columna
Host
(por ejemplo, '144.155.166.%'
para conseguir cualquier IP en una subred), alguien podría intentar explotar esta capacidad poniéndole a su cliente el nombre 144.155.166.cualquierhost.com
. Para evitar estos intentos, MySQL no permite que los comodines sean utilizados para los nombres de cliente que empiezan con dígitos y un punto. Así que si tiene un cliente con nombre similar a 1.2.cualquierhost.com
, su nombre nunca concordará con la columna Host
de las tablas grant. Un comodín de IP solo puede concordar con números IP, no nombres de cliente.
En la columna
User
, los caracteres comodín no están permitidos, pero puede especificar un valor en blanco, que será válido para cualquier nombre. Si el registro de la tabla user
que concuerda con una conexión entrante tiene un valor vacio, el usuario es considerado anónimo, sin nombre de usuario, no un usuario con el nombre que el cliente especificó realmente. Esto significa que el nombre de usuario vacío es utilizado para todas las comprobaciones de acceso posteriores durante la duración de la conexión (es decir, durante el Estado 2).
La columna
Password
puede estar vacía. Esto no es un comodín que permite que cualquier clave sea permitida. Significa que el usuario debe conectarse sin especificar una clave.
Los valores que no están vacíos de
Password
en la tabla user
representan claves cifradas. MySQL no almacena las claves en forma de texto llano para que cualquiera pueda verlo. En vez de esto, la clave suministrada por un usuario que se está intentando conetar es cifrada (utilizando la función PASSWORD()
). La clave cifrada se utiliza entonces durante el proceso de conexión en el momento de comprobar si es correcta. (Esto se realiza sin que la clave cifrada viaje nunca sobre la conexión.) Desde el punto de vista de MySQL, la clave cifrada es la clave REAL, así que no debería darse acceso a ella a nadie. En concreto, no de acceso de lectura a las tablas de la base de datos mysql
a usuarios no-administrativos.
MySQL 5.0 utiliza el método de autenticación más fuerte (implementado primeramente en MySQL 4.1) y que tiene una mejor protección de la clave durante el proceso de conexión que versiones previas. Es seguro aún cuando los paquetes TCP/IP fuesen interceptados o la base de datos
mysql
capturada. El cifrado de claves es comentado en mayor profundida en Sección 5.6.9, “Hashing de contraseñas en MySQL 4.1”.
Los siguientes ejemplos nos enseñan como se aplicarían a las conexiones entrantes diferentes combinaciones de los valores de las columnas
Host
y User
de la tabla user
.Cliente Valor | Usuario Valor | Conexiones que concuerdan con la entrada Entry |
'thomas.loc.gov' | 'fred' | fred , conectando desde thomas.loc.gov |
'thomas.loc.gov' | '' | Cualquier usuario, conectando desde thomas.loc.gov |
'%' | 'fred' | fred , conectando desde cualquier cliente |
'%' | '' | Cualquier usuario conectando desde cualquier cliente |
'%.loc.gov' | 'fred' | fred , conectando desde cualquier cliente en el dominioloc.gov |
'x.y.%' | 'fred' | fred , conectando desde x.y.net , x.y.com , x.y.edu , etc. (esto, probablemente, no es útil) |
'144.155.166.177' | 'fred' | fred , conectando desde el cliente con dirección IP144.155.166.177 |
'144.155.166.%' | 'fred' | fred , conectando desde cualquier cliente en la subred de clase C 144.155.166 |
'144.155.166.0/255.255.255.0' | 'fred' | Idéntico al ejemplo anterior |
Es posible que el nobre del cliente y del usuario de una conexión entrante concuerde con más de un registro en la tabla
user
. El conjunto de ejemplos precedentes demuestra esto: Algunas de las entradas mostradas concuerdan con una conexión de fred
desde thomas.loc.gov
.
Cuando hay la posibilidad de múltiples concordancias, el servidor debe determinar cual de ellas utilizar. El problema se resuelve de la siguiente manera:
- Siempre que el servidor lee la tabla
user
a memoria, ordena los registros. - Cuando un cliente intenta conectar, el servidor mira a través de los registros en el orden establecido.
- El servidor utiliza el primer registro que concuerda con el nombre y usuario del cliente.
Para ver como esto ocurre, supongamos que la tabla
user
es como esta:+-----------+----------+-| Host | User | …+-----------+----------+-| % | jeffrey || % | root | …… | localhost | root | …---------+----------+-| localhost | | … +--
Cuando el servidor lee la tabla, ordena las entradas con los valores de
Host
más específicos primero. Los nombres de cliente y números de IP son los más específicos. El comodín '%'
significa ``cualquier cliente'' y es menos específico. Registros con el mismo valor de Host
se ordenan con el valor de User
más específico (un valor de User
en blanco significa ``cualquier usuario'' y es menos específico). En la tabla user
recién mostrada, el resultado después de ordenar sería el siguiente:+-----------+----------+-| Host | User | …+-----------+----------+-... | localhost | || localhost | root | …… ... | % | jeffrey | … ...-----+----------+-| % | root | … ... +------
Cuando un cliente intenta conectar, el servidor mira los registros ordenados y utiliza la primera concordancia. Para una conexión desde
localhost
por jeffrey
, dos de las entradas de la tabla concuerdan: la primera con los valores 'localhost'
y ''
de Host
y User
respectivamente, y el registro con los valores '%'
y 'jeffrey'
. El registro con valor 'localhost'
aparece primero en la tabla ordenada, así que es el que el servidor utiliza.
Aquí hay otro ejemplo. Supongamos que la tabla
user
tiene el siguiente aspecto:+----------------+----------+-| Host | User | …+----------------+----------+-| thomas.loc.gov | || % | jeffrey | ……--------------+----------+-+- -
La tabla ordenada sería:
+----------------+----------+-| Host | User | …+----------------+----------+-| % | jeffrey || thomas.loc.gov | | ……--------------+----------+-+- -
Una conexión de
jeffrey
desde thomas.loc.gov
concuerda con el primer registro, mientras que una conexión de jeffrey
desde whitehouse.gov
concuerda con el segundo.
Es una confusión común el pensar que, para un nombre de usuario dado, todos los registros que nombran explícitamente con a ese usuario son utilizadas primero cuando el servidor intenta encontrar una concordancia para una conexión. Esto es sencillamente falso. El ejemplo anterior ilustra esto, donde una conexión de
jeffrey
desde thomas.loc.gov
no concuerda primero con el registro que contiene 'jeffrey'
como valor en la columnaUser
, sino que ha concordado con el registro que no contiene nombre de usuario. Como resultado, jeffrey
es tratado como un usuario anónimo aunque ha especificado un nombre de usuario al conectarse.
Si puede conectar al servidor, pero sus privilegios no son los que espera, probablemente está siendo identificado como algún otro usuario. Para averiguar qué cuenta de usuario utilizó el servidor para identificarle, use la función
CURRENT_USER()
. Devuelve un valor en formato user_name
@host_name
que indica los valores de User
y Host
del registro concordante en la tabla user
. Suponga que jeffrey
conecta y ejecuta la siguiente sentencia:mysql> SELECT CURRENT_USER();+----------------++----------------+| CURRENT_USER() | | @localhost |+----------------+
El resultado mostrado indica que el registro que concuerda en la tabla
user
tiene un valor vacío en la columnaUser
. En otras palabras, el servidor trata a jeffrey
como a un usuario anónimo.
Otra cosa que puede hacer para localizar problemas de autentificación es imprimir por pantalla la tabla
user
y ordenarla a mano para ver donde está la primera concordancia. Consulte Sección 12.9.3, “Funciones de información”.
Fuente:enlace
No hay comentarios:
Publicar un comentario