Seguridad

Problemas generales de seguridad

Esta sección describe los problemas generales de seguridad que debe tener en cuenta y lo que puede hacer para que su instalación de MySQL sea más segura contra ataques o uso indebido. Para obtener información específica sobre el sistema de control de acceso que utiliza MySQL para configurar cuentas de usuario y verificar el acceso a la base de datos.

Pautas Generales de Seguridad

Al hablar de seguridad, es necesario considerar la protección total de todo el servidor (no solo el servidor MySQL) contra todos los tipos de ataques aplicables: escuchas, alteraciones, reproducción y denegación de servicio. Aquí no cubrimos todos los aspectos de disponibilidad y tolerancia a fallas.

Cuando ejecute MySQL, siga las siguientes pautas:

  • ¡Nunca le dé a nadie (excepto  cuenta root MySQL ) acceso a la tabla user en la base de datos mysql del sistema! Esto es fundamental.

  • Aprenda cómo funciona el sistema de privilegios de acceso MySQL. Utilice las instrucciones GRANT y REVOKE para controlar el acceso a MySQL. No otorgue más privilegios de los necesarios. Nunca otorgue privilegios a todos los hosts.

    Lista de Verificación:

    • Prueba mysql -u root. Si puede conectarse con éxito al servidor sin que se le solicite una contraseña, ¡cualquiera puede conectarse a su servidor MySQL como usuario root de MySQL con todos los privilegios! Revise las instrucciones de instalación de MySQL, prestando especial atención a la información sobre cómo establecer una contraseña aroot.

    • Utilice el estado de cuenta SHOW GRANTS para comprobar qué cuentas tienen acceso a qué. Luego use la declaración REVOKE para eliminar los privilegios que no son necesarios.

- No almacene contraseñas de texto sin cifrar en su base de datos. Si su computadora se ve comprometida, el intruso puede tomar la lista completa de contraseñas y usarlas. En su lugar, utilice SHA2() o alguna otra función hash unidireccional y almacene el valor hash.

Para evitar la recuperación de contraseñas mediante tablas de arco iris, no utilice estas funciones con una contraseña simple; en su lugar, elija alguna cadena para usar como `salt` y use valores hash (hash (contraseña) + `salt`).

  • No elija contraseñas de diccionarios. Existen programas especiales para romper contraseñas. Incluso contraseñas como " xfish98 " son muy malas. Mucho mejor es " duag98 ", que contiene la misma palabra " pez " pero tecleó una tecla a la izquierda en un teclado QWERTY estándar. Otro método es usar una contraseña que se toma de los primeros caracteres de cada palabra en una oración (por ejemplo, " Hace cuatro y siete años " da como resultado una contraseña de " Fsasya "). La contraseña es fácil de recordar y escribir, pero difícil de adivinar para alguien que no conoce la oración. En este caso, puede sustituir adicionalmente dígitos por las palabras numéricas para obtener la frase " 4 puntaje y hace 7 años " , dando como resultado la contraseña " 4sa7ya " que es aún más difícil de adivinar.

  • Invierte en un cortafuegos. Esto lo protege de al menos el 50% de todos los tipos de exploits en cualquier software. Ponga MySQL detrás del firewall o en una zona desmilitarizada (DMZ).

    Lista de Verificación:

    • Intente escanear sus puertos desde Internet usando una herramienta como nmap. MySQL usa el puerto 3306 por defecto. Este puerto no debe ser accesible desde hosts que no sean de confianza. Como una forma simple de verificar si su puerto MySQL está abierto, pruebe el siguiente comando desde alguna máquina remota, donde server_hostestá el nombre de host o la dirección IP del host en el que se ejecuta su servidor MySQL:

      $> telnet server_host 3306

      Si telnet se cuelga o se rechaza la conexión, el puerto se bloquea, que es lo que desea que sea. Si obtiene una conexión y algunos caracteres basura, el puerto está abierto y debería estar cerrado en su firewall o enrutador, a menos que realmente tenga una buena razón para mantenerlo abierto.

  • Las aplicaciones que acceden a MySQL no deben confiar en los datos ingresados ​​por los usuarios y deben escribirse utilizando técnicas de programación defensivas adecuadas.

  • No transmita datos simples (sin cifrar) a través de Internet. Esta información es accesible para todo aquel que tenga el tiempo y la capacidad de interceptarla y utilizarla para sus propios fines. En su lugar, utilice un protocolo encriptado como SSL o SSH. MySQL admite conexiones SSL internas. Otra técnica consiste en utilizar el reenvío de puertos SSH para crear un túnel cifrado (y comprimido) para la comunicación.

  • Aprenda a utilizar las utilidades tcpdump y strings . En la mayoría de los casos, puede verificar si los flujos de datos de MySQL no están encriptados emitiendo un comando como el siguiente:

    $> tcpdump -l -i eth0 -w - src or dst port 3306 | strings

    Esto funciona en Linux y debería funcionar con pequeñas modificaciones en otros sistemas.

    Advertencia

    Si no ve datos en texto sin cifrar, esto no siempre significa que la información esté realmente encriptada. Si necesita alta seguridad, consulte con un experto en seguridad.

Mantener las contraseñas seguras

Cuando ejecuta un programa cliente para conectarse al servidor MySQL, no es aconsejable especificar su contraseña de una manera que la exponga al descubrimiento de otros usuarios. Los métodos que puede utilizar para especificar su contraseña cuando ejecuta programas cliente se enumeran aquí, junto con una evaluación de los riesgos de cada método. En resumen, los métodos más seguros son hacer que el programa cliente solicite la contraseña o especificar la contraseña en un archivo de opciones debidamente protegido.

  • Utilice una opción o en la línea de comando. Por ejemplo: --password=*password*``-p*password*

    $> mysql -u francis -pfrank db_name

    Advertencia

    Esto es conveniente pero inseguro . En algunos sistemas, su contraseña se vuelve visible para los programas de estado del sistema, como ps, que pueden ser invocados por otros usuarios para mostrar líneas de comando. Los clientes de MySQL normalmente sobrescriben el argumento de la contraseña de la línea de comandos con ceros durante su secuencia de inicialización. Sin embargo, todavía hay un breve intervalo durante el cual el valor es visible. Además, en algunos sistemas esta estrategia de sobrescritura es ineficaz y la contraseña permanece visible para ps . (Los sistemas SystemV Unix y quizás otros están sujetos a este problema).

    Si su entorno operativo está configurado para mostrar su comando actual en la barra de título de la ventana de su terminal, la contraseña permanece visible mientras el comando se está ejecutando, incluso si el comando se ha desplazado fuera de la vista en el área de contenido de la ventana.

  • Utilice la opción --password o -p en la línea de comando sin especificar ningún valor de contraseña. En este caso, el programa cliente solicita la contraseña de forma interactiva:

    $> mysql -u francis -p db_name
Enter password: ********

    Los caracteres * indican dónde ingresa su contraseña. La contraseña no se muestra cuando la ingresa.

    Es más seguro ingresar su contraseña de esta manera que especificarla en la línea de comando porque no es visible para otros usuarios. Sin embargo, este método de ingresar una contraseña es adecuado solo para programas que se ejecutan de forma interactiva. Si desea invocar a un cliente desde un script que se ejecuta de forma no interactiva, no hay oportunidad de ingresar la contraseña desde el teclado. En algunos sistemas, incluso puede encontrar que la primera línea de su secuencia de comandos se lee e interpreta (incorrectamente) como su contraseña.

  • Guarde su contraseña en un archivo de opciones. Por ejemplo, en Unix, puede incluir su contraseña en la [client]sección del .my.cnfarchivo en su directorio de inicio:

    [client]
password=password

    Para mantener la contraseña segura, nadie más que usted puede acceder al archivo. Para garantizar esto, configure el modo de acceso a archivos en 400o 600. Por ejemplo:

    $> chmod 600 .my.cnf

    Para nombrar desde la línea de comando un archivo de opciones específico que contiene la contraseña, use la opción, donde es el nombre completo de la ruta al archivo. Por ejemplo: --defaults-file=*file_name* file_name

    $> mysql --defaults-file=/home/francis/mysql-opts

En Unix, el cliente mysql escribe un registro de las declaraciones ejecutadas en un archivo histórico. De forma predeterminada, este archivo se nombra .mysql_historyy se crea en su directorio personal. Las contraseñas se pueden escribir como texto sin formato en declaraciones SQL como [CREATE USER] y [ALTER USER], por lo que si usa estas declaraciones, se registran en el archivo de historial. Para mantener este archivo seguro, use un modo de acceso restrictivo, de la misma manera que se describió anteriormente para el .my.cnfarchivo.

Si su intérprete de comandos mantiene un historial, cualquier archivo en el que se guarden los comandos contiene contraseñas MySQL ingresadas en la línea de comandos. Por ejemplo, bash usa ~/.bash_history. Cualquier archivo de este tipo debe tener un modo de acceso restrictivo.

Directrices del administrados para la seguridad de la contraseña

Los administradores de bases de datos deben utilizar las siguientes pautas para mantener seguras las contraseñas.

MySQL almacena las contraseñas de las cuentas de usuario en la tabla mysql.user del sistema. El acceso a esta tabla nunca debe otorgarse a ninguna cuenta no administrativa.

Las contraseñas de las cuentas pueden caducar, por lo que los usuarios deben restablecerlas.

El complemento validate_password se puede utilizar para hacer cumplir una política sobre contraseñas aceptables.

Conrtaseñas y registro

Las contraseñas se pueden escribir como texto sin formato en declaraciones SQL como [CREATE USER], [GRANT] y [SET PASSWORD]. Si el servidor MySQL registra tales declaraciones tal como están escritas, las contraseñas en ellas se vuelven visibles para cualquiera que tenga acceso a los registros.

El registro de declaraciones evita escribir contraseñas como texto sin cifrar para las siguientes declaraciones:

CREATE USER ... IDENTIFIED BY ...
ALTER USER ... IDENTIFIED BY ...
SET PASSWORD ...
START SLAVE ... PASSWORD = ...
START REPLICA ... PASSWORD = ...
CREATE SERVER ... OPTIONS(... PASSWORD ...)
ALTER SERVER ... OPTIONS(... PASSWORD ...)

Las contraseñas de esas declaraciones se reescriben para que no aparezcan literalmente en el texto de la declaración escrito en el registro de consultas general, el registro de consultas lentas y el registro binario. La reescritura no se aplica a otras declaraciones. En particular, las declaraciones [INSERT] o [UPDATE] para la  tsbls mysql.user del sistema que se refieren a contraseñas literales se registran tal cual, por lo que debe evitar dichas declaraciones.

Para el registro de consultas general, se puede suprimir la reescritura de contraseñas iniciando el servidor con la opción [--log-raw]. Por razones de seguridad, esta opción no se recomienda para uso en producción. Para fines de diagnóstico, puede ser útil ver el texto exacto de las declaraciones recibidas por el servidor.

De forma predeterminada, el contenido de los archivos de registro de auditoría producidos por el complemento de registro de auditoría no está cifrado y puede contener información confidencial, como el texto de las declaraciones SQL. Por razones de seguridad, los archivos de registro de auditoría deben escribirse en un directorio accesible solo para el servidor MySQL y para los usuarios con una razón legítima para ver el registro. 

Una implicación de la reescritura de contraseñas es que las declaraciones que no se pueden analizar (debido, por ejemplo, a errores de sintaxis) no se escriben en el registro de consultas general porque no se puede saber que estén libres de contraseña. Los casos de uso que requieren el registro de todas las declaraciones, incluidas aquellas con errores, deben usar la --log-rawopción, teniendo en cuenta que esto también evita la reescritura de contraseñas.

Las réplicas almacenan la contraseña del servidor de origen de la replicación en su repositorio de metadatos de conexión, que de forma predeterminada es una tabla en la mysqlbase de datos denominada slave_master_info. El uso de un archivo en el directorio de datos para el repositorio de metadatos de conexión ahora está en desuso, pero aún es posible. Asegúrese de que solo el administrador de la base de datos pueda acceder al repositorio de metadatos de conexión. Una alternativa para almacenar la contraseña en el repositorio de metadatos de conexión es usar la declaración [START REPLICA] (o antes de MySQL 8.0.22 [START SLAVE]) o [START GROUP_REPLICATION] para especificar las credenciales para conectarse a la fuente.

Utilice un modo de acceso restringido para proteger las copias de seguridad de la base de datos que incluyen tablas de registro o archivos de registro que contienen contraseñas.

Mantener MySql seguro para sus atacantes

Cuando se conecta a un servidor MySQL, debe usar una contraseña. La contraseña no se transmite como texto sin cifrar a través de la conexión.

El resto de la información se transfiere como texto y cualquier persona que pueda ver la conexión puede leerla. Si la conexión entre el cliente y el servidor pasa por una red que no es de confianza y esto le preocupa, puede utilizar el protocolo comprimido para hacer que el tráfico sea mucho más difícil de descifrar. También puede utilizar el soporte SSL interno de MySQL para hacer que la conexión sea aún más segura.Alternativamente, use SSH para obtener una conexión TCP IP encriptada entre un servidor MySQL y un cliente MySQL.

Para hacer que un sistema MySQL sea seguro, debe considerar seriamente las siguientes sugerencias:

  • Requiere que todas las cuentas MySQL tengan una contraseña. Un programa de cliente no necesariamente conoce la identidad de la persona que lo ejecuta. Es común para las aplicaciones cliente servidor que el usuario pueda especificar cualquier nombre de usuario en el programa cliente. Por ejemplo, cualquiera puede usar el programa mysql  para conectarse como cualquier otra persona simplemente invocándolo como si no tuviera contraseña. Si todas las cuentas tienen contraseña, la conexión con la cuenta de otro usuario se vuelve mucho más difícil. mysql -u *other_user* *db_name*other_user

  • Asegúrese de que la única cuenta de usuario de Unix con privilegios de lectura o escritura en los directorios de la base de datos sea la cuenta que se utiliza para ejecutar [mysqld].

  • Nunca ejecute el servidor MySQL como root usuario de Unix. Esto es extremadamente peligroso.

En su lugar, mysqld puede (y debe) ejecutarse como un usuario ordinario y sin privilegios. Puede crear una cuenta Unix separada nombrada mysql para que todo sea aún más seguro. Utilice esta cuenta solo para administrar MySQL. Para iniciar mysqld como un usuario de Unix diferente, agregue una user opción que especifique el nombre de usuario en el grupo [mysqld] del archivo de opciones my.cnf donde especifica las opciones del servidor. Por ejemplo:

```
[mysqld]
user=mysql
```

Esto hace que el servidor se inicie como el usuario designado, ya sea que lo inicie manualmente o mediante mysqld_safe o mysql.server.

Ejecutar mysqld como un usuario de Unix distinto de root no significa que deba cambiar el nombre root de usuario en la table user. Los nombres de usuario de las cuentas MySQL no tienen nada que ver con los nombres de usuario de las cuentas Unix .

  • No otorgue el provolegio [FILE] a usuarios no administrativos. Cualquier usuario que tenga este privilegio puede escribir un archivo en cualquier lugar del sistema de archivos con los privilegios del demonio [mysqld]. Esto incluye el directorio de datos del servidor que contiene los archivos que implementan las tablas de privilegios Para que las operaciones con privilegios [FILE] sean un poco más seguras, los archivos generados con [SELECT ... INTO OUTFILE] no sobrescriben los archivos existentes y todos pueden escribirlos.

  • Cifre los archivos de registro binarios y los archivos de registro de retransmisión. El cifrado ayuda a proteger estos archivos y los datos potencialmente confidenciales contenidos en ellos contra el uso indebido de atacantes externos y también contra la visualización no autorizada por parte de los usuarios del sistema operativo donde se almacenan. Habilita el cifrado en un servidor MySQL estableciendo la varible[binlog_encryption] del sistema en ON. 

  • No otorgue el privilegio [PROCESS] o [SUPER] a usuarios no administrativos. La salida de [mysqladmin processlist]( y [SHOW PROCESSLIST](muestra el texto de las declaraciones que se están ejecutando actualmente, por lo que cualquier usuario al que se le permita ver la lista de procesos del servidor podría ver las declaraciones emitidas por otros usuarios.

  • No permita el uso de enlaces simbólicos a tablas. (Esta capacidad se puede desactivar con la [--skip-symbolic-links]. Esto es especialmente importante si ejecuta [mysqld] como root, porque cualquiera que tenga acceso de escritura al directorio de datos del servidor podría eliminar cualquier archivo del sistema. 

  • Si no confía en su DNS, debe utilizar direcciones IP en lugar de nombres de host en las tablas de concesión. En cualquier caso, debe tener mucho cuidado al crear entradas en la tabla de concesiones utilizando valores de nombre de host que contengan comodines.

  • Si desea restringir el número de conexiones permitidas a una sola cuenta, puede hacerlo configurando la variable [max_user_connections] en [mysqld].

Control de acceso y gestión de cuentas

Nombres de ususario y contraseñas de las cuentas

MySQL almacena cuentas en la tabla user de la base de datos mysql del sistema. Una cuenta se define en términos de un nombre de usuario y el host o hosts del cliente desde los cuales el usuario puede conectarse al servidor.

Hay varias distinciones entre la forma en que MySQL y su sistema operativo utilizan los nombres de usuario y las contraseñas:

  • Los nombres de usuario, tal como los usa MySQL con fines de autenticación, no tienen nada que ver con los nombres de usuario (nombres de inicio de sesión) tal como los usa Windows o Unix. En Unix, la mayoría de los clientes MySQL intentan iniciar sesión de forma predeterminada con el nombre de usuario actual de Unix como nombre de usuario de MySQL, pero eso es solo por conveniencia. El valor predeterminado se puede anular fácilmente, porque los programas cliente permiten especificar cualquier nombre de usuario con una opción -u o --user. Esto significa que cualquiera puede intentar conectarse al servidor utilizando cualquier nombre de usuario, por lo que no puede hacer que una base de datos sea segura de ninguna manera a menos que todas las cuentas MySQL tengan contraseñas. Cualquiera que especifique un nombre de usuario para una cuenta que no tiene contraseña puede conectarse correctamente al servidor.

  • Los nombres de usuario de MySQL tienen hasta 32 caracteres. Los nombres de usuario del sistema operativo pueden tener una longitud máxima diferente.

    Advertencia:

    El límite de longitud del nombre de usuario de MySQL está codificado en los servidores y clientes de MySQL, y tratar de eludirlo modificando las definiciones de las tablas en la base de datos mysql no funciona .

    Nunca debe alterar la estructura de las tablas en la base de datos mysql de ninguna manera, excepto por medio del procedimiento que se describe en la Sección 2.11, "Actualización de MySQL" . Intentar redefinir las tablas del sistema de MySQL de cualquier otra forma da como resultado un comportamiento indefinido y sin soporte. El servidor es libre de ignorar las filas que se deforman como resultado de tales modificaciones.

  • Para autenticar las conexiones del cliente para las cuentas que utilizan métodos de autenticación integrados, el servidor utiliza contraseñas almacenadas en la tabla user. Estas contraseñas son distintas de las contraseñas para iniciar sesión en su sistema operativo. No hay una conexión necesaria entre la contraseña " externa " que usa para iniciar sesión en una máquina Windows o Unix y la contraseña que usa para acceder al servidor MySQL en esa máquina.

    Si el servidor autentica a un cliente mediante algún otro complemento, el método de autenticación que implementa el complemento puede utilizar o no una contraseña almacenada en la tabla user. En este caso, es posible que también se utilice una contraseña externa para autenticarse en el servidor MySQL.

  • Las contraseñas almacenadas en la tabla user se cifran mediante algoritmos específicos del complemento.

  • Si el nombre de usuario y la contraseña contienen solo caracteres ASCII, es posible conectarse al servidor independientemente de la configuración del juego de caracteres. Para habilitar las conexiones cuando el nombre de usuario o la contraseña contienen caracteres que no son ASCII, las aplicaciones cliente deben llamar a la mysql_options()función API de C con la opción MYSQL_SET_CHARSET_NAME y el nombre del juego de caracteres apropiado como argumentos. Esto hace que la autenticación se lleve a cabo utilizando el juego de caracteres especificado. De lo contrario, la autenticación falla a menos que el juego de caracteres predeterminado del servidor sea el mismo que la codificación en los valores predeterminados de autenticación.

El proceso de instalación de MySQL llena las tablas de [permisos] con una cuenta inicial root. A partir de entonces, se establece normalmente hasta, modificar y eliminar cuentas de MySQL usando frases como [CREATE USER], [DROP USER], [GRANT], y [REVOKE].

Para conectarse a un servidor MySQL con un cliente de línea de comandos, especifique las opciones de nombre de usuario y contraseña según sea necesario para la cuenta que desea usar:

$> mysql --user=finley --password db_name

Si prefiere opciones cortas, el comando se ve así:

$> mysql -u finley -p db_name

Si omite el valor de la contraseña después de la opción [--password] o -p en la línea de comando (como se acaba de mostrar), el cliente solicita una. Alternativamente, la contraseña se puede especificar en la línea de comando:

$> mysql --user=finley --password=password db_name
$> mysql -u finley -ppassword db_name
Si usa la -popción, no debe haber ningún espacio entre -pel siguiente valor de contraseña. La especificación de una contraseña en la línea de comando debe considerarse insegura.

Privilegios proporcionados por MySQL

6.2.2 Privilegios proporcionados por MySQL

Los privilegios otorgados a una cuenta MySQL determinan qué operaciones puede realizar la cuenta. Los privilegios de MySQL difieren en los contextos en los que se aplican y en los diferentes niveles de operación:

  • Los privilegios administrativos permiten a los usuarios administrar el funcionamiento del servidor MySQL. Estos privilegios son globales porque no son específicos de una base de datos en particular.

  • Los privilegios de la base de datos se aplican a una base de datos y a todos los objetos que contiene. Estos privilegios se pueden otorgar para bases de datos específicas o globalmente para que se apliquen a todas las bases de datos.

  • Se pueden otorgar privilegios para objetos de base de datos como tablas, índices, vistas y rutinas almacenadas para objetos específicos dentro de una base de datos, para todos los objetos de un tipo dado dentro de una base de datos (por ejemplo, todas las tablas en una base de datos), o globalmente para todos. objetos de un tipo determinado en todas las bases de datos.

Los privilegios también difieren en términos de si son estáticos (integrados en el servidor) o dinámicos (definidos en tiempo de ejecución). El hecho de que un privilegio sea estático o dinámico afecta su disponibilidad para otorgarse a las cuentas y los roles de los usuarios. Para obtener información sobre las diferencias entre privilegios estáticos y dinámicos.

La información sobre los privilegios de la cuenta se almacena en las tablas de concesión de la base de datos mysqldel sistema. El servidor MySQL lee el contenido de las tablas de [permisos] en la memoria cuando se inicia. El servidor basa las decisiones de control de acceso en las copias en memoria de las tablas de concesión.

Resumen de privilegios disponibles

La siguiente tabla muestra los nombres de privilegios estáticos utilizados en las declaraciones [GRANT] y [REVOKE], junto con el nombre de la columna asociada con cada privilegio en las tablas de concesión y el contexto en el que se aplica el privilegio.

Privilegios estáticos permitidos para GRANT y REVOKE

Privilegio Columna de tabla de GRANT Contexto
ALL [PRIVILEGES] Sinónimo de " todos los privilegios " Administración del servidor
ALTER Alter_priv Tables
ALTER ROUTINE Alter_routine_priv Rutinas almacenadas
CREATE Create_priv Bases de datos, tablas o índices
CREATE ROLE Create_role_priv Administración del servidor
CREATE ROUTINE Create_routine_priv Rutinas almacenadas
CREATE TABLESPACE Create_tablespace_priv Administración del servidor
CREATE TEMPORARY TABLES Create_tmp_table_priv Tables
CREATE USER Create_user_priv Administración del servidor
CREATE VIEW Create_view_priv views
DELETE Delete_priv Tables
DROP Drop_priv Bases de datos, tablas o vistas
DROP ROLE Drop_role_priv Administración del servidor
EVENT Event_priv Bases de datos
EXECUTE Execute_priv Rutinas almacenadas
FILE File_priv Acceso a archivos en el host del servidor
GRANT OPTION Grant_priv Bases de datos, tablas o rutinas almacenadas
INDEX Index_priv Tables
INSERT Insert_priv Tablas o columnas
LOCK TABLES Lock_tables_priv Bases de datos
PROCESS Process_priv Administración del servidor
PROXY Ver proxies_privtabla Administración del servidor
REFERENCES References_priv Bases de datos o tablas
RELOAD Reload_priv Administración del servidor
REPLICATION CLIENT Repl_client_priv Administración del servidor
REPLICATION SLAVE Repl_slave_priv Administración del servidor
SELECT Select_priv Tablas o columnas
SHOW DATABASES Show_db_priv Administración del servidor
SHOW VIEW Show_view_priv views
SHUTDOWN Shutdown_priv Administración del servidor
SUPER Super_priv Administración del servidor
TRIGGER Trigger_priv Tables
UPDATE Update_priv Tablas o columnas
USAGE Sinónimo de " sin privilegios " Administración del servidor

La siguiente tabla muestra los nombres de privilegios dinámicos utilizados en las declaraciones GRANTy REVOKE, junto con el contexto en el que se aplica el privilegio.

Privilegios dinámicos permitidos para GRANT y REVOKE

Privilegio Contexto
APPLICATION_PASSWORD_ADMIN Administración de contraseña dual
AUDIT_ADMIN Administración de registros de auditoría
BACKUP_ADMIN Administración de copias de seguridad
BINLOG_ADMIN Administración de copias de seguridad y replicación
BINLOG_ENCRYPTION_ADMIN Administración de copias de seguridad y replicación
CLONE_ADMIN Administración de clones
CONNECTION_ADMIN Administración del servidor
ENCRYPTION_KEY_ADMIN Administración del servidor
FIREWALL_ADMIN Administración de cortafuegos
FIREWALL_EXEMPT Administración de cortafuegos
FIREWALL_USER Administración de cortafuegos
FLUSH_OPTIMIZER_COSTS Administración del servidor
FLUSH_STATUS Administración del servidor
FLUSH_TABLES Administración del servidor
FLUSH_USER_RESOURCES Administración del servidor
GROUP_REPLICATION_ADMIN Administración de replicación
INNODB_REDO_LOG_ARCHIVE Rehacer la administración del archivo de registros
NDB_STORED_USER Clúster NDB
PERSIST_RO_VARIABLES_ADMIN Administración del servidor
REPLICATION_APPLIER PRIVILEGE_CHECKS_USER para un canal de replicación
REPLICATION_SLAVE_ADMIN Administración de replicación
RESOURCE_GROUP_ADMIN Administración de grupos de recursos
RESOURCE_GROUP_USER Administración de grupos de recursos
ROLE_ADMIN Administración del servidor
SESSION_VARIABLES_ADMIN Administración del servidor
SET_USER_ID Administración del servidor
SHOW_ROUTINE Administración del servidor
SYSTEM_USER Administración del servidor
SYSTEM_VARIABLES_ADMIN Administración del servidor
TABLE_ENCRYPTION_ADMIN Administración del servidor
VERSION_TOKEN_ADMIN Administración del servidor
XA_RECOVER_ADMIN Administración del servidor

Descripción de privilegios estáticos

Los privilegios estáticos están integrados en el servidor, a diferencia de los privilegios dinámicos, que se definen en tiempo de ejecución. La siguiente lista describe cada privilegio estático disponible en MySQL.

Es posible que determinadas sentencias de SQL tengan requisitos de privilegios más específicos que los indicados aquí. Si es así, la descripción de la declaración en cuestión proporciona los detalles.

  • [ALL], [ALL PRIVILEGES] Estos especificadores de privilegios son una abreviatura de " todos los privilegios disponibles en un nivel de privilegio determinado " (excepto [GRANT OPTION]). Por ejemplo, la concesión [ALL] a nivel global o de tabla otorga todos los privilegios globales o todos los privilegios a nivel de tabla, respectivamente.

  • [ALTER]

    Habilita el uso de la instrucción [ALTER TABLE] para cambiar la estructura de las tablas. 

  • [ALTER ROUTINE]

    Permite el uso de declaraciones que alteran o eliminan rutinas almacenadas (funciones y procedimientos almacenados). Para las rutinas que caen dentro del ámbito en el que se otorga el privilegio y para las que el usuario no es el usuario nombrado como rutina DEFINER, también permite el acceso a propiedades de rutina distintas de la definición de rutina.

  • [CREATE]

    Permite el uso de declaraciones que crean nuevas bases de datos y tablas.

  • [CREATE ROLE]

    Habilita el uso de la decalración [CREATE ROLE]. El provilegio [CREATE USER] también permite el uso de la declaración [CREATE ROLE].

  • [CREATE ROUTINE]

    Permite el uso de declaraciones que crean rutinas almacenadas (procedimientos y funciones almacenados).Para las rutinas que caen dentro del ámbito en el que se otorga el privilegio y para las que el usuario no es el usuario nombrado como rutina DEFINER, también permite el acceso a propiedades de rutina distintas de la definición de rutina.

  • [CREATE TABLESPACE]

    Permite el uso de declaraciones que crean, alteran o eliminan espacios de tabla y grupos de archivos de registro.

  • [CREATE TEMPORARY TABLES]

    Habilita la creación de tablas temporales usando la declaración [CREATE TEMPORARY TABLE].

  • [CREATE USER]

    Permite el uso de las declaraciones [ALTER USER], [CREATE ROLE], [CREATE USER], [DROP ROLE], [DROP USER], [RENAME USER], y [REVOKE ALL PRIVILEGES].

  • [CREATE VIEW]

    Habilita el uso de la  declaración [CREATE VIEW].

  • [DELETE]

    Permite eliminar filas de las tablas de una base de datos.

  • [DROP]

    Permite el uso de declaraciones que eliminan (eliminan) bases de datos, tablas y vistas existentes. 

  • [DROP ROLE]

    Habilita el uso de la declaración [DROP ROLE].

  • [EVENT]

    Permite el uso de declaraciones que crean, alteran, eliminan o muestran eventos para el Programador de eventos.

  • [EXECUTE]

    Habilita el uso de sentencias que ejecutan rutinas almacenadas (funciones y procedimientos almacenados).Para las rutinas que caen dentro del ámbito en el que se otorga el privilegio y para las que el usuario no es el usuario nombrado como rutina DEFINER, también permite el acceso a propiedades de rutina distintas de la definición de rutina.

  • [FILE]

    Afecta las siguientes operaciones y comportamientos del servidor:

    • Permite la lectura y escritura de archivos en el host de servidor utilizando las declaraciones [LOAD DATA] y [SELECT ... INTO OUTFILE] las declaraciones y la función[LOAD_FILE()]. Un usuario que tiene el privilegio [FILE] puede leer cualquier archivo en el host del servidor que sea legible en todo el mundo o legible por el servidor MySQL. (Esto implica que el usuario puede leer cualquier archivo en cualquier directorio de la base de datos, porque el servidor puede acceder a cualquiera de esos archivos).

    • Permite la creación de nuevos archivos en cualquier directorio donde el servidor MySQL tenga acceso de escritura. Esto incluye el directorio de datos del servidor que contiene los archivos que implementan las tablas de privilegios.

    • Habilita el uso de la opción de tabla DATA DIRECTORYo INDEX DIRECTORY para la declraración [CREATE TABLE].

    Como medida de seguridad, el servidor no sobrescribe los archivos existentes.

    Para limitar la ubicación en la que se pueden leer y escribir archivos, configure la variable de sistema [secure_file_priv] en un directorio específico.

  • [GRANT OPTION]

    Le permite otorgar o revocar a otros usuarios los privilegios que usted mismo posee.

- [INDEX]

Permite el uso de declaraciones que crean o eliminan (eliminan) índices.

  • [INSERT]

    Permite insertar filas en tablas en una base de datos. [

  • [LOCK TABLES]

    Habilita el uso de declaraciones [LOCK TABLES] explícitas para bloquear tablas para las que tiene el privilegio[SELECT]. Esto incluye el uso de bloqueos de escritura, lo que evita que otras sesiones lean la tabla bloqueada.

  • [PROCESS]

    El provolegio [PROCESS] controla el acceso a la información sobre los subprocesos que se ejecutan dentro del servidor (es decir, información sobre las sentencias que ejecutan las sesiones). Se puede acceder a la información del hilo disponible mediante la declaración[SHOW PROCESSLIST]y el [comando mysqladmin processlist].

    • Con el provolegio [PROCESS], un usuario tiene acceso a la información sobre todos los hilos, incluso los que pertenecen a otros usuarios.

    • Sin el privilegio [PROCESS], los usuarios no anónimos tienen acceso a la información sobre sus propios hilos, pero no los hilos de otros usuarios, y los usuarios anónimos no tienen acceso a la información del hilo.

  • [PROXY]

    Permite a un usuario hacerse pasar por otro usuario o ser conocido como otro. 

  • [REFERENCES]

    La creación de una restricción de clave externa requiere el provolegio [REFERENCES].

  • [RELOAD]

    El privilegio [RELOAD] habilita las siguientes operaciones:

    • Uso de la declaración [FLUSH].

    • El uso de comandos [mysqladmin] que son equivalentes a [FLUSH], las operaciones: flush-hosts, flush-logs, flush-privileges, flush-status, flush-tables, flush-threads, refresh, y reload.

    • Uso de opciones de [mysqldump]  que realizan varias operaciones [FLUSH].

    • Uso de las declaraciones [RESET MASTER] and [RESET REPLICA], [RESET SLAVE].

  • [REPLICATION CLIENT]

    Permite el uso de las declaraciones [SHOW MASTER STATUS], [SHOW REPLICA STATUS]y [SHOW BINARY LOGS].

  • [REPLICATION SLAVE]

    Permite que la cuenta solicite actualizaciones que se han realizado en las bases de datos en el servidor de origen de replicación, utilizando las declaraciones [SHOW REPLICAS], [SHOW SLAVE HOSTS] [SHOW RELAYLOG EVENTS], y [SHOW BINLOG EVENTS]. Otorgue este privilegio a las cuentas que utilizan las réplicas para conectarse al servidor actual como su servidor de origen de replicación.

  • [SELECT]

    Permite seleccionar filas de tablas en una base de datos. Las declaraciones requieren el provolegio [SELECT] solo si realmente acceden a las tablas. Algunas [SELECT] sentencias no acceden a tablas y se pueden ejecutar sin permiso para cualquier base de datos. Por ejemplo, puede usarlo [SELECT] como una calculadora simple para evaluar expresiones que no hacen referencia a tablas:

    SELECT 1+1;
SELECT PI()*2;

  • [SHOW DATABASES]

    Permite que la cuenta vea los nombres de las bases de datos al emitir la declaración SHOW DATABASE.Las cuentas que no tienen este privilegio ven solo las bases de datos para las que tienen algunos privilegios y no pueden usar la declaración en absoluto si el servidor se inició con la opción [--skip-show-database].

    Precaución

    Debido a que cualquier privilegio global estático se considera un privilegio para todas las bases de datos, cualquier privilegio global estático permite al usuario ver todos los nombres de las bases de datos con [SHOW DATABASES].

  • [SHOW VIEW]

    Habilita el uso de la decalración [SHOW CREATE VIEW] declaración. 

  • [SHUTDOWN]

    Habilita el uso de las declaraciones [SHUTDOWN].

- [SUPER]

[`SUPER`] es un privilegio **poderoso** y de gran alcance y no debe concederse a la ligera. Si una cuenta necesita realizar solo un subconjunto de [`SUPER`] operaciones, es osible lograr el conjunto de privilegios deseado otorgando en su lugar uno o más privilegios dinámicos, cada uno de los cuales confiere capacidades más limitadas.

  • [TRIGGER]

    Habilita las operaciones de activación. Debe tener este privilegio para que una tabla cree, elimine, ejecute o muestre activadores para esa tabla.

    Cuando se activa un disparador (por un usuario que tiene privilegios para ejecutar [INSERT], [UPDATE] o [DELETE]), la ejecución del disparador requiere que el usuario que definió el disparador aún tenga el privilegio [TRIGGER] para la tabla.

  • [UPDATE]

    Permite que las filas se actualicen en tablas en una base de datos.

  • [USAGE]

    Este especificador de privilegios significa "sin privilegios". " Se utiliza a nivel global con [GRANT]para especificar cláusulas como, por ejemplo, WITH GRANT OPTION sin nombrar privilegios de cuenta específicos en la lista de privilegios. 

Descripciones de privilegios dinámicos

Los privilegios dinámicos se definen en tiempo de ejecución, a diferencia de los privilegios estáticos, que están integrados en el servidor. La siguiente lista describe cada privilegio dinámico disponible en MySQL.

La mayoría de los privilegios dinámicos se definen al iniciar el servidor. Otros están definidos por un componente o complemento en particular, como se indica en las descripciones de privilegios. En tales casos, el privilegio no está disponible a menos que el componente o complemento que lo define esté habilitado.

Es posible que determinadas sentencias de SQL tengan requisitos de privilegios más específicos que los indicados aquí. Si es así, la descripción de la declaración en cuestión proporciona los detalles.

  • [APPLICATION_PASSWORD_ADMIN]

    Para la capacidad de doble contraseña, este privilegio permite el uso de la cláusulas RETAIN CURRENT PASSWORDy DISCARD OLD PASSWORD para las declaraciones [ALTER USER] y [SET PASSWORD] que se aplican a su propia cuenta. Este privilegio es necesario para manipular su propia contraseña secundaria porque la mayoría de los usuarios solo requieren una contraseña.

    Si se va a permitir que una cuenta manipule contraseñas secundarias para todas las cuentas, se le debe otorgar el provolegio [CREATE USER].

  • [AUDIT_ADMIN]

    Habilita la configuración del registro de auditoría. 

  • [BACKUP_ADMIN]

    Habilita la ejecución de la declaración [LOCK INSTANCE FOR BACKUP].

  • [BINLOG_ADMIN]

    Habilita el control de registros binarios mediante las instrucciones [PURGE BINARY LOGS].

  • [BINLOG_ENCRYPTION_ADMIN]

    Habilita la configuración de la variable del sistema [binlog_encryption], que activa o desactiva el cifrado para archivos de registro binarios y archivos de registro de retransmisión. Esta capacidad no es proporcionado por los provilegios [BINLOG_ADMIN], [SYSTEM_VARIABLES_ADMIN] o [SESSION_VARIABLES_ADMIN]. 

  • [CLONE_ADMIN]

    Habilita la ejecución de las declaraciones CLONE. Incluye privilegios [BACKUP_ADMIN] y [SHUTDOWN].

  • [CONNECTION_ADMIN]

    Habilita el uso de la instrucción [KILL] instrucción o el [comando mysqladmin kill] para eliminar los subprocesos que pertenecen a otras cuentas. (Una cuenta siempre puede matar sus propios hilos).

    Permite configurar las variables del sistema relacionadas con las conexiones del cliente o eludir las restricciones relacionadas con las conexiones del cliente. [CONNECTION_ADMIN] se aplica a los efectos de estas variables del sistema:

    • [init_connect]: El servidor no ejecuta el contenido [init_connect] de la variable del sistema cuando los [CONNECTION_ADMIN] clientes se conectan.

    • [max_connections]: El servidor acepta una conexión de un cliente [CONNECTION_ADMIN] incluso si [max_connections] se alcanza el límite de conexión configurado por la variable del sistema.

    • [offline_mode]: Un servidor en modo fuera de línea ( [offline_mode] no finaliza las conexiones [CONNECTION_ADMIN] del cliente en la siguiente solicitud del cliente y acepta nuevas conexiones de los clientes [CONNECTION_ADMIN].

    • [read_only]: Las actualizaciones se pueden realizar incluso cuando la varible [read_only]del sistema está habilitada. Esto se aplica a las actualizaciones de tablas explícitas y al uso de declaraciones de administración de cuentas como [GRANT] y [REVOKE] que actualizan tablas de manera implícita.

  • [ENCRYPTION_KEY_ADMIN]

    Habilita la rotación InnoDB de claves de cifrado.

- [FIREWALL_ADMIN]

Permite a un usuario administrar reglas de firewall para cualquier usuario.

  • [FIREWALL_EXEMPT] (agregado en MySQL 8.0.27)

    Un usuario con este privilegio está exento de las restricciones de firewall.

- [FIREWALL_USER]

Permite a los usuarios actualizar sus propias reglas de firewall.

  • FLUSH_OPTIMIZER_COSTS

    Habilita el uso de la decalración [FLUSH OPTIMIZER_COSTS].

  • [FLUSH_STATUS] (agregado en MySQL 8.0.23)

    Habilita el uso de [FLUSH STATUS]

  • [FLUSH_TABLES] (agregado en MySQL 8.0.23)

    Habilita el uso de la [FLUSH TABLES]

  • [FLUSH_USER_RESOURCES] (agregado en MySQL 8.0.23)

    Habilita el uso de la [FLUSH USER_RESOURCES]

  • [GROUP_REPLICATION_ADMIN]

    Permite que la cuenta inicie y detenga la replicación de grupo mediante las instrucciones [START GROUP REPLICATION]y [STOP GROUP REPLICATION]

  • [INNODB_REDO_LOG_ARCHIVE]

    Permite que la cuenta active y desactive el archivado de registros de rehacer.

  • [INNODB_REDO_LOG_ENABLE]

    Habilita el uso de la [ALTER INSTANCE {ENABLE|DISABLE} INNODB REDO_LOG] declaración para habilitar o deshabilitar el registro de rehacer. Introducido en MySQL 8.0.21.

  • [NDB_STORED_USER]

    Permite que el usuario o rol y sus privilegios sean compartidos y sincronizados entre todos los servidores NDB MySQL habilitados tan pronto como se unan a un determinado NDB Cluster. 

    Cualquier cambio o revocación de privilegios realizados para el usuario o rol dado se sincroniza inmediatamente con todos los servidores MySQL conectados (nodos SQL). Debe tener en cuenta que no hay garantía de que se ejecuten varias sentencias que afecten a los privilegios que se originan en diferentes nodos SQL en todos los nodos SQL en el mismo orden. Por este motivo, se recomienda encarecidamente que toda la administración de usuarios se realice desde un único nodo SQL designado.

    NDB_STORED_USER es un privilegio global y debe concederse o revocarse mediante ON *.*. Si intenta establecer cualquier otro ámbito para este privilegio, se producirá un error. Este privilegio se puede otorgar a la mayoría de los usuarios administrativos y de aplicaciones, pero no se puede otorgar a cuentas reservadas del sistema como mysql.session@localhosto mysql.infoschema@localhost.

    Un usuario al que se le ha otorgado el privilegio NDB_STORED_USER se almacena en NDB (y por lo tanto, todos los nodos SQL lo comparten), al igual que un rol con este privilegio. Un usuario al que simplemente se le concede un rol que noNDB_STORED_USER está almacenado ; a cada usuario almacenado se le debe otorgar el privilegio explícitamente.

  • [PERSIST_RO_VARIABLES_ADMIN]

    Para los usuarios que también lo han hecho [SYSTEM_VARIABLES_ADMIN],  [PERSIST_RO_VARIABLES_ADMIN] habilita el uso de [SET PERSIST_ONLY] para conservar las variables del sistema global en el mysqld-auto.cnf archivo de opciones en el directorio de datos. 

  • [REPLICATION_APPLIER]

    Permite que la cuenta actúe como canal de replicación PRIVILEGE_CHECKS_USER y ejecute declaraciones BINLOG en la salida de [mysqlbinlog]. Otorgue este privilegio a las cuentas asignadas mediante CHANGE REPLICATION SOURCE TO o [CHANGE MASTER TO] (antes de MySQL 8.0.23) para proporcionar un contexto de seguridad para los canales de replicación y para manejar los errores de replicación en esos canales.

  • [REPLICATION_SLAVE_ADMIN]

    Activa la cuenta para conectarse al servidor de origen de replicación, la replicación iniciar y dejar de usar las declaraciones [START REPLICA] y [STOP REPLICA], y el uso de la declaración [CHANGE REPLICATION SOURCE TO] (de MySQL 8.0.23) o [CHANGE MASTER TO] (antes de MySQL 8.0.23) Otorgue este privilegio a las cuentas que utilizan las réplicas para conectarse al servidor actual como su servidor de origen de replicación. Este privilegio no se aplica a la replicación de grupo; utilizar GROUP_REPLICATION_ADMINpara eso.

  • [RESOURCE_GROUP_ADMIN]

    Habilita la administración de grupos de recursos, que consiste en crear, modificar y eliminar grupos de recursos, y asignar subprocesos y declaraciones a grupos de recursos. Un usuario con este privilegio puede realizar cualquier operación relacionada con los grupos de recursos.

  • [RESOURCE_GROUP_USER]

    Permite la asignación de subprocesos y declaraciones a grupos de recursos. Un usuario con este privilegio puede usar la declaración [SET RESOURCE GROUP] y la [RESOURCE_GROUP] sugerencia del optimizador.

  • [ROLE_ADMIN] Habilita la concesión y revocación de roles, el uso de la cláusula WITH ADMIN OPTION

  • [SERVICE_CONNECTION_ADMIN]

    Habilita las conexiones a la interfaz de red que solo permite conexiones administrativas .

  • [SESSION_VARIABLES_ADMIN] (agregado en MySQL 8.0.14)

    Para la mayoría de las variables del sistema, configurar el valor de la sesión no requiere privilegios especiales y cualquier usuario puede hacerlo para afectar la sesión actual. Para algunas variables del sistema, establecer el valor de la sesión puede tener efectos fuera de la sesión actual y, por lo tanto, es una operación restringida. Para estos, el privolegio [SESSION_VARIABLES_ADMIN] permite al usuario establecer el valor de la sesión.

  • [SHOW_ROUTINE]

    Permite a un usuario acceder a las definiciones y propiedades de todas las rutinas almacenadas (procedimientos y funciones almacenados), incluso aquellas para las que el usuario no se nombra como rutina DEFINER. Este acceso incluye:

    • El contenido de la tabla [INFORMATION_SCHEMA.ROUTINES].

    • Las declaraciones [SHOW CREATE FUNCTION] y [SHOW CREATE PROCEDURE].

    • Las declaraciones [SHOW FUNCTION CODE] y [SHOW PROCEDURE CODE].

    • Las declaraciones [SHOW FUNCTION STATUS] y [SHOW PROCEDURE STATUS].

    Antes de MySQL 8.0.20, para que un usuario acceda a definiciones de rutinas que el usuario no definió, el usuario debe tener el [SELECT].

  • [SYSTEM_USER] (agregado en MySQL 8.0.16)

    El privilegio [SYSTEM_USER] distingue a los usuarios del sistema de los usuarios habituales:

    • Un usuario con privilegio [SYSTEM_USER] privilegios es un usuario del sistema.

    • Un usuario sin privilegio [SYSTEM_USER] es un usuario regular.

    El [SYSTEM_USER] tiene un efecto en las cuentas a las que un usuario determinado puede aplicar sus otros privilegios, así como en si el usuario está protegido de otras cuentas:

    • Un usuario del sistema puede modificar tanto las cuentas regulares como las del sistema. Es decir, un usuario que tiene los privilegios adecuados para realizar una operación determinada en cuentas regulares está habilitado mediante la posesión de [SYSTEM_USER] para realizar también la operación en cuentas del sistema. Una cuenta del sistema solo puede ser modificada por los usuarios del sistema con los privilegios adecuados, no por los usuarios habituales.

    • Un usuario habitual con los privilegios adecuados puede modificar las cuentas habituales, pero no las del sistema. Tanto el sistema como los usuarios habituales pueden modificar una cuenta normal con los privilegios adecuados.

  • [SYSTEM_VARIABLES_ADMIN]

    Afecta las siguientes operaciones y comportamientos del servidor:

    • Habilita cambios de variables del sistema en tiempo de ejecución.

    • Permite cambios en las características de las transacciones globales.

  • [TABLE_ENCRYPTION_ADMIN] (agregado en MySQL 8.0.16)

    Permite a un usuario anular la configuración de cifrado predeterminada cuando [table_encryption_privilege_check] está habilitado.

  • [VERSION_TOKEN_ADMIN]

    Habilita la ejecución de funciones de tokens de versión. Este privilegio lo define el version_tokenscomplemento.

  • [XA_RECOVER_ADMIN]

    Habilita la ejecución de la declaración [XA RECOVER].

Pautas para la concesión de privilegios

Es una buena idea otorgar a una cuenta solo los privilegios que necesita. Debe tener especial cuidado al otorgar los privilegios administrativos:

  • [FILE] se puede abusar para leer en una tabla de base de datos cualquier archivo que el servidor MySQL pueda leer en el host del servidor. Esto incluye todos los archivos y archivos legibles en todo el mundo en el directorio de datos del servidor.

  • [GRANT OPTION] permite a los usuarios dar sus privilegios a otros usuarios. Dos usuarios que tienen diferentes privilegios y con el [GRANT OPTION] pueden combinar privilegios.

  • [ALTER] se puede utilizar para subvertir el sistema de privilegios cambiando el nombre de las tablas.

  • [SHUTDOWN] se puede abusar para denegar el servicio a otros usuarios por completo al finalizar el servidor.

  • [PROCESS] se puede utilizar para ver el texto sin formato de las sentencias que se están ejecutando actualmente, incluidas las sentencias que establecen o cambian las contraseñas.

  • [SUPER] se puede utilizar para finalizar otras sesiones o cambiar el funcionamiento del servidor.

  • Los privilegios otorgados a la base de datos mysql del sistema en sí se pueden usar para cambiar contraseñas y otra información de privilegios de acceso:

    • Las contraseñas se almacenan cifradas, por lo que un usuario malintencionado no puede simplemente leerlas para conocer la contraseña de texto sin formato. Sin embargo, un usuario con acceso de escritura a la columna de la tabla del sistema mysql.user authentication_string puede cambiar la contraseña de una cuenta y luego conectarse al servidor MySQL usando esa cuenta.

    • [INSERT] o [UPDATE] concedidos para la base de datos mysql del sistema permiten a un usuario agregar privilegios o modificar los privilegios existentes, respectivamente.

    • [DROP] para la base de datos mysql del sistema permite a un usuario privilegiar tablas de forma remota, o incluso la propia base de datos.

Privilegios estáticos versus dinámicos

MySQL admite privilegios estáticos y dinámicos:

  • Los privilegios estáticos están integrados en el servidor. Siempre están disponibles para concederse a las cuentas de usuario y no se puedes qeliminar del registro.

  • Los privilegios dinámicos se pueden registrar y anular el registro en tiempo de ejecución. Esto afecta su disponibilidad: no se puede otorgar un privilegio dinámico que no se haya registrado.

Por ejemplo, los privilegios [SELECT] y [INSERT] son estáticos y siempre están disponibles, mientras que un privilegio dinámico está disponible solo si el componente que lo implementa ha sido habilitado.

El resto de esta sección describe cómo funcionan los privilegios dinámicos en MySQL. La discusión utiliza el término " componentes " pero se aplica igualmente a los complementos.

Nota

Los administradores del servidor deben saber qué componentes del servidor definen los privilegios dinámicos. Para las distribuciones MySQL, la documentación de los componentes que definen los privilegios dinámicos describe esos privilegios.

Los componentes de terceros también pueden definir privilegios dinámicos;un administrador debe comprender esos privilegios y no instalar componentes que puedan entrar en conflicto o comprometer el funcionamiento del servidor. Por ejemplo, un componente entra en conflicto con otro si ambos definen un privilegio con el mismo nombre. Los desarrolladores de componentes pueden reducir la probabilidad de que esto ocurra eligiendo nombres de privilegios que tengan un prefijo basado en el nombre del componente.

El servidor mantiene el conjunto de privilegios dinámicos registrados internamente en la memoria. La cancelación del registro ocurre cuando se apaga el servidor.

Normalmente, un componente que define privilegios dinámicos los registra cuando se instala, durante su secuencia de inicialización. Cuando se desinstala, un componente no anula el registro de sus privilegios dinámicos registrados. (Esta es una práctica actual, no un requisito. Es decir, los componentes podrían anular el registro en cualquier momento de los privilegios que registran, pero no lo hacen).

No se produce ninguna advertencia o error para los intentos de registrar un privilegio dinámico ya registrado. Considere la siguiente secuencia de declaraciones:

INSTALL COMPONENT 'my_component';
UNINSTALL COMPONENT 'my_component';
INSTALL COMPONENT 'my_component';

La primera instrucción [INSTALL COMPONENT] registra los privilegios definidos por componente my_component, pero [UNINSTALL COMPONENT] no los cancela. Para la segunda [INSTALL COMPONENT], los privilegios del componente que registra ya están registrados, pero no se producen advertencias ni errores.

Los privilegios dinámicos se aplican solo a nivel global. El servidor almacena información sobre las asignaciones actuales de privilegios dinámicos a las cuentas de usuario en la tabla mysql.global_grants del sistema:

  • El servidor registra automáticamente los privilegios nombrados global_grants durante el inicio del servidor (a menos que [--skip-grant-tables] se dé la opción).

  • Las declaraciones [GRANT] y [REVOKE] modifican el contenido de global_grants.

  • Las asignaciones de privilegios dinámicos enumerados en global_grantsson persistentes. No se eliminan cuando se apaga el servidor.

Ejemplo: la siguiente declaración otorga al usuario u1los privilegios necesarios para controlar la replicación (incluida la replicación de grupo) en una réplica y para modificar las variables del sistema:

GRANT REPLICATION_SLAVE_ADMIN, GROUP_REPLICATION_ADMIN, BINLOG_ADMIN
ON *.* TO 'u1'@'localhost';

Los privilegios dinámicos otorgados aparecen en la salida de la declaración SHOW GRANTS y la tabla INFORMATION_SCHEMA [USER_PRIVILEGES].

Para [GRANT] y [REVOKE] a nivel global, cualquier privilegio con nombre no reconocido como estático se compara con el conjunto actual de privilegios dinámicos registrados y se otorga si se encuentra. De lo contrario, se produce un error para indicar un identificador de privilegios desconocido.

Para [GRANT] y [REVOKE] el significado de ALL [PRIVILEGES] a nivel global incluye todos los privilegios globales estáticos, así como todos los privilegios dinámicos registrados actualmente:

  • GRANT ALL a nivel global otorga todos los privilegios globales estáticos y todos los privilegios dinámicos registrados actualmente. Un privilegio dinámico registrado después de la ejecución de la declaración GRANT no se otorga retroactivamente a ninguna cuenta.

  • REVOKE ALL a nivel global revoca todos los privilegios globales estáticos otorgados y todos los privilegios dinámicos otorgados.

La declaración [FLUSH PRIVILEGES] lee la tabla global_grants de asignaciones de privilegios dinámicos y registra los privilegios no registrados que se encuentran allí.

Especificación de nombres de cuenta

Los nombres de cuentas de MySQL consisten en un nombre de usuario y un nombre de host, lo que permite la creación de cuentas distintas para usuarios con el mismo nombre de usuario que se conectan desde diferentes hosts. Esta sección describe la sintaxis de los nombres de cuenta, incluidos los valores especiales y las reglas de comodines.

En la mayoría de los aspectos, los nombres de las cuentas son similares a los nombres de los roles de MySQL, con algunas diferencias .

Los nombres de cuenta aparecen en las sentencias SQL como [CREATE USER], [GRANT] y [SET PASSWORD] y siguen estas reglas:

  • La sintaxis del nombre de cuenta es . '*user_name*'@'*host_name*'

  • La '@'host_name' es opcional. Un nombre de cuenta que consta solo de un nombre de usuario es equivalente a 'user_name'@'%'. Por ejemplo 'me', es equivalente a 'me'@'%'. 

  • No es necesario citar el nombre de usuario y el nombre de host si son válidos como identificadores sin comillas. Deben usarse comillas si una cadena user_name contiene caracteres especiales (como espacios o -), o si una cadena host_name contiene caracteres especiales o caracteres comodín (como .o %).Por ejemplo, en el nombre de la cuenta 'test-user'@'%.com', tanto el nombre de usuario como el nombre de host requieren comillas.

  • Las partes del nombre de usuario y del nombre de host, si se citan, deben citarse por separado. Es decir, escribe 'me'@'localhost', no 'me@localhost'. Este último es en realidad equivalente a 'me@localhost'@'%'.

  • Una referencia a la función [CURRENT_USER] o [CURRENT_USER()] equivale a especificar literalmente el nombre de usuario y el nombre de host del cliente actual.

MySQL almacena los nombres de las cuentas en tablas de permisos en la base de datos mysql del sistema usando columnas separadas para el nombre de usuario y las partes del nombre de host:

  • La  tabla user contiene una fila para cada cuenta. Las columnas Usery Host almacenan el nombre de usuario y el nombre de host. Esta tabla también indica qué privilegios globales tiene la cuenta.

  • Otras tablas de concesión indican los privilegios que tiene una cuenta para bases de datos y objetos dentro de bases de datos. Estas tablas tienen Usery Hostcolumnas para almacenar el nombre de cuenta. Cada fila de estas tablas se asocia con la cuenta de la usertabla que tiene los mismos valores Usery Host.

  • Para fines de verificación de acceso, las comparaciones de los valores de usuario distinguen entre mayúsculas y minúsculas. Las comparaciones de valores de Host no distinguen entre mayúsculas y minúsculas.

Los nombres de usuario y los nombres de host tienen ciertos valores especiales o convenciones de comodines, como se describe a continuación.

La parte del nombre de usuario de un nombre de cuenta es un valor no blanco que coincide literalmente con el nombre de usuario para los intentos de conexión entrantes, o un valor en blanco (la cadena vacía) que coincide con cualquier nombre de usuario. Una cuenta con un nombre de usuario en blanco es un usuario anónimo. Para especificar un usuario anónimo en las sentencias SQL, utilice una parte de nombre de usuario vacía entre comillas, como ''@'localhost'.

La parte del nombre de host de un nombre de cuenta puede adoptar muchas formas y se permiten comodines:

  • Un valor de host puede ser un nombre de host o una dirección IP (IPv4 o IPv6). El nombre 'localhost'indica el host local. La dirección IP '127.0.0.1' indica la interfaz de bucle invertido IPv4. La dirección IP '::1'indica la interfaz de bucle invertido IPv6.

  • Los caracteres comodín %y _están permitidos en los valores de nombre de host o dirección IP. Tienen el mismo significado que para las operaciones de coincidencia de patrones realizadas con el operador [LIKE]. Por ejemplo, un valor de host de '%'coincide con cualquier nombre de host, mientras que un valor de '%.mysql.com'coincide con cualquier host del dominio mysql.com. '198.51.100.%'coincide con cualquier host en la red clase C 198.51.100.

    Debido a que los valores de comodín de IP están permitidos en los valores de host (por ejemplo, '198.51.100.%'para hacer coincidir cada host en una subred), alguien podría intentar explotar esta capacidad nombrando un host 198.51.100.somewhere.com. Para frustrar tales intentos, MySQL no realiza coincidencias en nombres de host que comienzan con dígitos y un punto. Por ejemplo, si se nombra un host 1.2.example.com, su nombre nunca coincide con la parte del host de los nombres de cuenta. Un valor de comodín de IP solo puede coincidir con direcciones IP, no con nombres de host.

  • Para un valor de host especificado como una dirección IPv4, se puede proporcionar una máscara de red para indicar cuántos bits de dirección se deben usar para el número de red. La notación de máscara de red no se puede utilizar para direcciones IPv6.

    La sintaxis es. Por ejemplo: *host_ip*/*netmask*

    CREATE USER 'david'@'198.51.100.0/255.255.255.0';

    Esto permite davidconectarse desde cualquier host cliente que tenga una dirección IP client_ippara la que se cumpla la siguiente condición:

    client_ip & netmask = host_ip

    Es decir, para la declaración [CREATE USER] que se acaba de mostrar:

    client_ip & 255.255.255.0 = 198.51.100.0

    Las direcciones IP que satisfacen esta condición van de 198.51.100.0a 198.51.100.255.

    Una máscara de red normalmente comienza con bits establecidos en 1, seguidos de bits establecidos en 0. Ejemplos:

    • 198.0.0.0/255.0.0.0: Cualquier host en la red 198 clase A

    • 198.51.0.0/255.255.0.0: Cualquier host en la red 198.51 clase B

    • 198.51.100.0/255.255.255.0: Cualquier host en la red 198.51.100 clase C

    • 198.51.100.1: Solo el host con esta dirección IP específica

  • A partir de MySQL 8.0.23, un valor de host especificado como una dirección IPv4 se puede escribir usando notación CIDR, como 198.51.100.44/24.

El servidor realiza la comparación de los valores de host en los nombres de cuenta con el host del cliente utilizando el valor devuelto por el sistema de resolución de DNS para el nombre de host del cliente o la dirección IP. Excepto en el caso de que el valor del host de la cuenta se especifique mediante la notación de máscara de red, el servidor realiza esta comparación como una coincidencia de cadena, incluso para un valor de host de la cuenta dado como una dirección IP. Esto significa que debe especificar los valores de host de la cuenta en el mismo formato que usa DNS. A continuación, se muestran ejemplos de problemas a los que debe prestar atención:

  • Suponga que un host en la red local tiene un nombre completo de host1.example.com. Si el DNS devuelve búsquedas de nombres para este host como host1.example.com, use ese nombre en los valores de host de la cuenta. Si DNS devuelve solo host1, utilice host1en su lugar.

  • Si el DNS devuelve la dirección IP de un host dado como 198.51.100.2, eso coincide con el valor de host de la cuenta, 198.51.100.2pero no 198.051.100.2. Del mismo modo, coincide con un patrón de host de cuenta como 198.51.100.%pero no 198.051.100.%.

Para evitar problemas como estos, es recomendable verificar el formato en el que su DNS devuelve los nombres y direcciones de host. Utilice valores en el mismo formato en los nombres de las cuentas de MySQL.

Control de acceso. Etapa 1: Verificación de conexión.

Cuando intenta conectarse a un servidor MySQL, el servidor acepta o rechaza la conexión en función de estas condiciones:

  • Su identidad y si puede verificarla proporcionando las credenciales adecuadas.

  • Si su cuenta está bloqueada o desbloqueada.

El servidor comprueba primero las credenciales y luego el estado de bloqueo de la cuenta. Una falla en cualquiera de los pasos hace que el servidor le niegue el acceso por completo. De lo contrario, el servidor acepta la conexión y luego entra en la Etapa 2 y espera las solicitudes.

El servidor realiza la verificación de identidad y credenciales utilizando columnas en la usertabla, aceptando la conexión solo si se cumplen estas condiciones:

  • El nombre de host del cliente y el nombre de usuario coinciden con las columnas Hosty Useren alguna userfila de la tabla. Para conocer las reglas que rigen los valores permitidos Hosty User.

  • El cliente proporciona las credenciales especificadas en la fila (por ejemplo, una contraseña), como se indica en la columna authentication_string. Las credenciales se interpretan utilizando el complemento de autenticación mencionado en la columna plugin.

  • La fila indica que la cuenta está desbloqueada. El estado de bloqueo se registra en la columna account_locked, que debe tener un valor de 'N'. El bloqueo de la cuenta se puede configurar o cambiar con la declaración [CREATE USER] o [ALTER USER].

Su identidad se basa en dos datos:

  • Su nombre de usuario de MySQL.

  • El host del cliente desde el que se conecta.

Si el valor de la columna User no está en blanco, el nombre de usuario en una conexión entrante debe coincidir exactamente. Si el valor User está en blanco, coincide con cualquier nombre de usuario. Si la fila user de la tabla que coincide con una conexión entrante tiene un nombre de usuario en blanco, se considera que el usuario es un usuario anónimo sin nombre, no un usuario con el nombre que el cliente realmente especificó. Esto significa que se utiliza un nombre de usuario en blanco para todas las comprobaciones de acceso posteriores durante la conexión (es decir, durante la Etapa 2).

La columna authentication_string puede estar en blanco. Esto no es un comodín y no significa que coincida ninguna contraseña. Significa que el usuario debe conectarse sin especificar una contraseña. El método de autenticación implementado por el complemento que autentica al cliente puede o no usar la contraseña en la columna authentication_string. En este caso, es posible que también se utilice una contraseña externa para autenticarse en el servidor MySQL.

Los valores de contraseña que no están en blanco almacenados en la columna authentication_string de la user tabla están cifrados. MySQL no almacena las contraseñas como texto sin cifrar para que nadie las vea. Más bien, la contraseña proporcionada por un usuario que intenta conectarse está encriptada (utilizando el método de hash de contraseña implementado por el complemento de autenticación de cuenta). La contraseña cifrada se utiliza durante el proceso de conexión para comprobar si la contraseña es correcta. Esto se hace sin que la contraseña encriptada viaje a través de la conexión.

Desde el punto de vista de MySQL, la contraseña cifrada es la contraseña real , por lo que nunca debe permitir que nadie acceda a ella. En particular, no otorgue a los usuarios no administrativos acceso de lectura a las tablas de la mysqlbase de datos del sistema .

La siguiente tabla muestra cómo se aplican las distintas combinaciones de valores Usery Hostde la usertabla a las conexiones entrantes.

User Valor Host Valor Conexiones permitidas
'fred' 'h1.example.net' fred, conectando desde h1.example.net
'' 'h1.example.net' Cualquier usuario que se conecte desde h1.example.net
'fred' '%' fred, conectando desde cualquier host
'' '%' Cualquier usuario, conectándose desde cualquier host
'fred' '%.example.net' fred, conectándose desde cualquier host del example.netdominio
'fred' 'x.example.%' fred, Conectando de x.example.net, x.example.com, x.example.edu, y así sucesivamente; esto probablemente no sea útil
'fred' '198.51.100.177' fred, conectándose desde el host con dirección IP 198.51.100.177
'fred' '198.51.100.%' fred, conectándose desde cualquier host en la 198.51.100subred clase C
'fred' '198.51.100.0/255.255.255.0' Igual que el ejemplo anterior

Es posible que el nombre de host del cliente y el nombre de usuario de una conexión entrante coincidan con más de una fila en la tabla user. El conjunto de ejemplos anterior demuestra esto: varias de las entradas que se muestran coinciden con una conexión de h1.example.netpor fred.

Cuando son posibles varias coincidencias, el servidor debe determinar cuál de ellas utilizar. Resuelve este problema de la siguiente manera:

  • Siempre que el servidor lee la tabla user en la memoria, ordena las filas.

  • Cuando un cliente intenta conectarse, el servidor examina las filas en orden.

  • El servidor utiliza la primera fila que coincide con el nombre de host del cliente y el nombre de usuario.

El servidor utiliza reglas de clasificación que ordenan Host primero las filas con los valores más específicos :

  • Las direcciones IP literales y los nombres de host son los más específicos.

  • Antes de MySQL 8.0.23, la especificidad de una dirección IP literal no se ve afectada por el hecho de que tiene una máscara de red, por lo que 198.51.100.13y 198.51.100.0/255.255.255.0se consideran igualmente específicas. A partir de MySQL 8.0.23, las cuentas con una dirección IP en la parte del host tienen este orden de especificidad:

    • Cuentas que tienen la parte de host dada como una dirección IP:

      CREATE USER 'user_name'@'127.0.0.1';
CREATE USER 'user_name'@'198.51.100.44';

    • Cuentas que tienen la parte del host dada como una dirección IP usando la notación CIDR:

      CREATE USER 'user_name'@'192.0.2.21/8';
CREATE USER 'user_name'@'198.51.100.44/16';

    • Cuentas que tienen la parte del host dada como una dirección IP con una máscara de subred:

      CREATE USER 'user_name'@'192.0.2.0/255.255.255.0';
CREATE USER 'user_name'@'198.51.0.0/255.255.0.0';

  • El patrón '%'significa " cualquier anfitrión " y es el menos específico.

  • La cadena vacía ''también significa " cualquier host " pero ordena después '%'.

las Non-TCP conexiones (archivo de socket, tubería con nombre, y la memoria compartida) se tratan como conexiones locales y coincide con la parte de host localhostsi hay algún tipo de cuentas, o partes de acogida con comodines que responden a localhost otro modo (por ejemplo, local%, l%, %).

Las filas con el mismo valor Host se ordenan con los valores User más específicos primero.Un valor User en blanco significa " cualquier usuario " y es menos específico, por lo que para las filas con el mismo valor Host, los usuarios no anónimos ordenan antes que los usuarios anónimos.

Para filas con valores Host y igualmente específicos User, el orden no es determinista.

Para ver cómo funciona esto, suponga que la tabla user se ve así:

+-----------+----------+-
| Host      | User     | ...
+-----------+----------+-
| %         | root     | ...
| %         | jeffrey  | ...
| localhost | root     | ...
| localhost |          | ...
+-----------+----------+-

Cuando el servidor lee la tabla en la memoria, ordena las filas usando las reglas que se acaban de describir. El resultado después de ordenar se ve así:

+-----------+----------+-
| Host      | User     | ...
+-----------+----------+-
| localhost | root     | ...
| localhost |          | ...
| %         | jeffrey  | ...
| %         | root     | ...
+-----------+----------+-

Cuando un cliente intenta conectarse, el servidor examina las filas ordenadas y utiliza la primera coincidencia encontrada. Para una conexión de localhostpor jeffrey, dos de las filas de la tabla coinciden: la que tiene los valores Hosty User de 'localhost'y '', y la que tiene los valores de '%'y 'jeffrey'. La 'localhost' fila aparece primero en orden, por lo que es la que usa el servidor.

He aquí otro ejemplo. Suponga que la tabla user tiene este aspecto:

+----------------+----------+-
| Host           | User     | ...
+----------------+----------+-
| %              | jeffrey  | ...
| h1.example.net |          | ...
+----------------+----------+-

La tabla ordenada se ve así:

+----------------+----------+-
| Host           | User     | ...
+----------------+----------+-
| h1.example.net |          | ...
| %              | jeffrey  | ...
+----------------+----------+-

La primera fila coincide con una conexión de cualquier usuario desde h1.example.net, mientras que la segunda fila coincide con una conexión jeffreyde cualquier host.

Nota

Es un error común pensar que, para un nombre de usuario dado, todas las filas que nombran explícitamente a ese usuario se utilizan primero cuando el servidor intenta encontrar una coincidencia para la conexión.Esto no es verdad. El ejemplo anterior ilustra esto, donde una conexión de h1.example.netpor jeffreyprimero no coincide con la fila que contiene 'jeffrey'el valor User de la columna, sino con la fila sin nombre de usuario. Como resultado, jeffreyse autentica como un usuario anónimo, aunque haya especificado un nombre de usuario al conectarse.

Si puede conectarse al servidor, pero sus privilegios no son los que esperaba, probablemente se esté autenticando como alguna otra cuenta. Para saber qué cuenta usó el servidor para autenticarte, usa la función [CURRENT_USER()]. Devuelve un valor en formato que indica los valores y de la fila de la tabla coincidente . Supongamos que conecta y emite la siguiente consulta: *user_name*@*host_name*``User``Host``user``jeffrey

mysql> SELECT CURRENT_USER();
+----------------+
| CURRENT_USER() |
+----------------+
| @localhost     |
+----------------+

El resultado que se muestra aquí indica que la fila user de la tabla coincidente tenía un valor User de columna en blanco . En otras palabras, el servidor lo trata jeffrey como un usuario anónimo.

Otra forma de diagnosticar problemas de autenticación es imprimir la tabla user y clasificarla a mano para ver dónde se realiza la primera coincidencia.

Control de acceso, etapa 2: solicitud de verificación

Una vez que el servidor acepta una conexión, ingresa a la Etapa 2 del control de acceso. Para cada solicitud que emita a través de la conexión, el servidor determina qué operación desea realizar y luego verifica si sus privilegios son suficientes. Aquí es donde entran en juego las columnas de privilegios en las tablas de subvenciones. Estos privilegios pueden provenir de cualquiera de las tablas user, global_grants, db, tables_priv, columns_priv, o procs_priv.

Agregar cuentas, asignar privilegios y cancelar cuentas

Para administrar cuentas MySQL, use las declaraciones SQL destinadas a ese propósito:

  • [CREATE USER] y [DROP USER] crear y eliminar cuentas.

  • [GRANT] y [REVOKE] asignar privilegios ay revocar privilegios de cuentas.

  • [SHOW GRANTS] muestra las asignaciones de privilegios de la cuenta.

Otra opción para crear cuentas es utilizar la herramienta GUI MySQL Workbench. Además, varios programas de terceros ofrecen capacidades para la administración de cuentas MySQL. phpMyAdmin es uno de esos programas.

En esta sección se tratan los siguientes temas:

  • [Creación de cuentas y concesión de privilegios]

  • [Verificación de privilegios y propiedades de la cuenta]

  • [Revocación de privilegios de cuenta]

  • [Eliminar cuentas]

Creación de cuentas y concesión de privilegios

Los siguientes ejemplos muestran cómo utilizar el programa cliente [mysql] para configurar nuevas cuentas. Estos ejemplos asumen que la root cuenta MySQL tiene el privilegio [CREATE USER] y todos los privilegios que otorga a otras cuentas.

En la línea de comando, conéctese al servidor como usuario root de MySQL , proporcionando la contraseña adecuada en el indicador de contraseña:

$> mysql -u root -p
Enter password: (enter root password here)

Después de conectarse al servidor, puede agregar nuevas cuentas. El siguiente ejemplo usa [CREATE USER]y [GRANT] para configurar cuatro cuentas (donde vea , sustituya una contraseña apropiada): '*password*'

CREATE USER 'finley'@'localhost'
  IDENTIFIED BY 'password';
GRANT ALL
  ON *.*
  TO 'finley'@'localhost'
  WITH GRANT OPTION;

CREATE USER 'finley'@'%.example.com'
  IDENTIFIED BY 'password';
GRANT ALL
  ON *.*
  TO 'finley'@'%.example.com'
  WITH GRANT OPTION;

CREATE USER 'admin'@'localhost'
  IDENTIFIED BY 'password';
GRANT RELOAD,PROCESS
  ON *.*
  TO 'admin'@'localhost';

CREATE USER 'dummy'@'localhost';

Las cuentas creadas por esos extractos tienen las siguientes propiedades:

  • Dos cuentas tienen un nombre de usuario de finley. Ambas son cuentas de superusuario con privilegios globales completos para hacer cualquier cosa. La cuenta 'finley'@'localhost' se puede usar solo cuando se conecta desde el host local. La cuenta 'finley'@'%.example.com' usa el '%'comodín en la parte del host, por lo que se puede usar para conectarse desde cualquier host del dominio example.com.

    La cuenta 'finley'@'localhost' es necesaria si hay una cuenta de usuario anónimo para localhost.Sin la cuenta 'finley'@'localhost', esa cuenta de usuario anónimo tiene prioridad cuando finley se conecta desde el host local y finleyse trata como un usuario anónimo. La razón de esto es que la cuenta de usuario anónimo tiene un valor Host de columna más específico que la cuenta 'finley'@'%' y, por lo tanto, aparece antes en el orden user de clasificación de la tabla. 

  • La cuenta 'admin'@'localhost' solo puede ser utilizada por admin para conectarse desde el host local. Se le conceden los privilegios globales [RELOAD] y [PROCESS] administrativos. Estos privilegios permiten al usuario admin ejecutar los comandos [mysqladmin reload], [mysqladmin refresh] y [mysqladmin flush-xxx], así como [mysqladmin processlist]. No se otorgan privilegios para acceder a ninguna base de datos. Puede agregar dichos privilegios mediante [GRANT].

  • La  cuenta 'dummy'@'localhost' no tiene contraseña (lo cual es inseguro y no recomendado). Esta cuenta solo se puede usar para conectarse desde el host local. No se conceden privilegios. Se supone que otorga privilegios específicos a la cuenta mediante [GRANT].

El ejemplo anterior otorga privilegios a nivel global. El siguiente ejemplo crea tres cuentas y les otorga acceso a niveles inferiores; es decir, a bases de datos u objetos específicos dentro de bases de datos. Cada cuenta tiene un nombre de usuario de custom, pero las partes del nombre de host difieren:

CREATE USER 'custom'@'localhost'
  IDENTIFIED BY 'password';
GRANT ALL
  ON bankaccount.*
  TO 'custom'@'localhost';

CREATE USER 'custom'@'host47.example.com'
  IDENTIFIED BY 'password';
GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,DROP
  ON expenses.*
  TO 'custom'@'host47.example.com';

CREATE USER 'custom'@'%.example.com'
  IDENTIFIED BY 'password';
GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,DROP
  ON customer.addresses
  TO 'custom'@'%.example.com';

Las tres cuentas se pueden utilizar de la siguiente manera:

  • La cuenta 'custom'@'localhost' tiene todos los privilegios de nivel de base de datos para acceder a la bd bankaccount. La cuenta se puede utilizar para conectarse al servidor solo desde el host local.

  • La cuenta 'custom'@'host47.example.com' tiene privilegios específicos a nivel de base de datos para acceder a la bd expenses. La cuenta se puede utilizar para conectarse al servidor solo desde el host host47.example.com.

  • La cuenta 'custom'@'%.example.com' tiene privilegios específicos a nivel de tabla para acceder a la tabla addresses en la bd customer, desde cualquier host del dominioexample.com. La cuenta se puede utilizar para conectarse al servidor desde todas las máquinas del dominio debido al uso del caracter % comodín en la parte del host del nombre de la cuenta.

Verificación de privilegios y propiedades de la cuenta

Para ver los privilegios de una cuenta, use [SHOW GRANTS]:

mysql> SHOW GRANTS FOR 'admin'@'localhost';
+-----------------------------------------------------+
| Grants for admin@localhost                          |
+-----------------------------------------------------+
| GRANT RELOAD, PROCESS ON *.* TO `admin`@`localhost` |
+-----------------------------------------------------+

Para ver las propiedades sin privilegios de una cuenta, use [SHOW CREATE USER]:

mysql> SET print_identified_with_as_hex = ON;
mysql> SHOW CREATE USER 'admin'@'localhost'\G
*************************** 1\. row ***************************
CREATE USER for admin@localhost: CREATE USER `admin`@`localhost`
IDENTIFIED WITH 'caching_sha2_password'
AS 0x24412430303524301D0E17054E2241362B1419313C3E44326F294133734B30792F436E77764270373039612E32445250786D43594F45354532324B6169794F47457852796E32
REQUIRE NONE PASSWORD EXPIRE DEFAULT ACCOUNT UNLOCK
PASSWORD HISTORY DEFAULT
PASSWORD REUSE INTERVAL DEFAULT
PASSWORD REQUIRE CURRENT DEFAULT

Habilitar la varianle [print_identified_with_as_hex] del sistema (disponible a partir de MySQL 8.0.17) hace [SHOW CREATE USER] que se muestren valores hash que contienen caracteres no imprimibles como cadenas hexadecimales en lugar de literales de cadena normales.

Revocación de privilegios de cuenta

Para revocar los privilegios de la cuenta, use [REVOKE]. Los privilegios se pueden revocar en diferentes niveles, al igual que se pueden otorgar en diferentes niveles.

Revocar privilegios globales:

REVOKE ALL
  ON *.*
  FROM 'finley'@'%.example.com';

REVOKE RELOAD
  ON *.*
  FROM 'admin'@'localhost';

Revocar privilegios de nivel de base de datos:

REVOKE CREATE,DROP
  ON expenses.*
  FROM 'custom'@'host47.example.com';

Revocar privilegios de nivel de tabla:

REVOKE INSERT,UPDATE,DELETE
  ON customer.addresses
  FROM 'custom'@'%.example.com';

Para comprobar el efecto de la revocación de privilegios, utilice [SHOW GRANTS](:

mysql> SHOW GRANTS FOR 'admin'@'localhost';
+---------------------------------------------+
| Grants for admin@localhost                  |
+---------------------------------------------+
| GRANT PROCESS ON *.* TO `admin`@`localhost` |
+---------------------------------------------+

Eliminar cuentas

Para eliminar una cuenta, use el [DROP USER]. Por ejemplo, para eliminar algunas de las cuentas creadas anteriormente:

DROP USER 'finley'@'localhost';
DROP USER 'finley'@'%.example.com';
DROP USER 'admin'@'localhost';
DROP USER 'dummy'@'localhost';

Uso de roles

Un rol de MySQL es una colección de privilegios con nombre. Al igual que las cuentas de usuario, los roles pueden tener privilegios otorgados y revocados.

A una cuenta de usuario se le pueden otorgar roles, lo que otorga a la cuenta los privilegios asociados con cada rol. Esto permite la asignación de conjuntos de privilegios a las cuentas y proporciona una alternativa conveniente a la concesión de privilegios individuales, tanto para conceptualizar las asignaciones de privilegios deseados como para implementarlos.

Crear roles y otorgarles privilegios

Considere este escenario:

  • Una aplicación usa una base de datos llamada app_db.

  • Asociadas con la aplicación, puede haber cuentas para los desarrolladores que crean y mantienen la aplicación y para los usuarios que interactúan con ella.

  • Los desarrolladores necesitan acceso completo a la base de datos. Algunos usuarios solo necesitan acceso de lectura, otros necesitan acceso de lectura / escritura.

Para evitar otorgar privilegios individualmente a posiblemente muchas cuentas de usuario, cree roles como nombres para los conjuntos de privilegios requeridos. Esto facilita la concesión de los privilegios necesarios a las cuentas de usuario mediante la concesión de los roles adecuados.

Para crear los roles, use [CREATE ROLE]:

CREATE ROLE 'app_developer', 'app_read', 'app_write';

Los nombres de roles son muy parecidos a los nombres de cuentas de usuario y constan de una parte de usuario y una parte de host en formato. La parte del host, si se omite, toma el valor predeterminado . Las partes del usuario y del host pueden estar sin comillas a menos que contengan caracteres especiales como o . A diferencia de los nombres de cuenta, la parte de usuario de los nombres de funciones no puede estar en blanco. 

Para asignar privilegios a los roles, ejecute [GRANT] usando la misma sintaxis que para asignar privilegios a las cuentas de usuario:

GRANT ALL ON app_db.* TO 'app_developer';
GRANT SELECT ON app_db.* TO 'app_read';
GRANT INSERT, UPDATE, DELETE ON app_db.* TO 'app_write';

Ahora suponga que inicialmente necesita una cuenta de desarrollador, dos cuentas de usuario que necesitan acceso de solo lectura y una cuenta de usuario que necesita acceso de lectura / escritura. Utilice [CREATE USER] para crear las cuentas:

CREATE USER 'dev1'@'localhost' IDENTIFIED BY 'dev1pass';
CREATE USER 'read_user1'@'localhost' IDENTIFIED BY 'read_user1pass';
CREATE USER 'read_user2'@'localhost' IDENTIFIED BY 'read_user2pass';
CREATE USER 'rw_user1'@'localhost' IDENTIFIED BY 'rw_user1pass';

Para asignar a cada cuenta de usuario sus privilegios requeridos, puede usar [GRANT] de la misma forma que se acaba de mostrar, pero eso requiere enumerar los privilegios individuales para cada usuario. En su lugar, use una sintaxis [GRANT] alternativa que permita otorgar roles en lugar de privilegios:

GRANT 'app_developer' TO 'dev1'@'localhost';
GRANT 'app_read' TO 'read_user1'@'localhost', 'read_user2'@'localhost';
GRANT 'app_read', 'app_write' TO 'rw_user1'@'localhost';

Definición de roles obligatorios

Es posible especificar roles como obligatorios nombrándolos en el valor de la variable [mandatory_roles] del sistema. El servidor trata un rol obligatorio como otorgado a todos los usuarios, por lo que no es necesario otorgarlo explícitamente a ninguna cuenta.

Para especificar roles obligatorios al inicio del servidor, defina [mandatory_roles] en su archivo my.cnf de servidor :

[mysqld]
mandatory_roles='role1,role2@localhost,r3@%.example.com'

Para establecer y persistir [mandatory_roles] en tiempo de ejecución, use una declaración como esta:

SET PERSIST mandatory_roles = 'role1,role2@localhost,r3@%.example.com';

[SET PERSIST] establece un valor para la instancia de MySQL en ejecución. También guarda el valor, lo que hace que se transfiera a los reinicios posteriores del servidor. Para cambiar el valor de la instancia de MySQL en ejecución sin que se transfiera a reinicios posteriores, use la palabra clave GLOBAL#### Comprobación de privilegios de rol

Para verificar los privilegios asignados a una cuenta, use SHOW GRANTS. Por ejemplo:

mysql> SHOW GRANTS FOR 'dev1'@'localhost'; +-------------------------------------------------+ | Grants for dev1@localhost | +-------------------------------------------------+ | GRANT USAGE ON *.* TOdev1@localhost| | GRANTapp_developer@%TOdev1@localhost| +-------------------------------------------------+

Sin embargo, eso muestra cada rol otorgado sin " expandirlo " a los privilegios que representa el rol. Para mostrar también los privilegios de roles, agregue una cláusula USING que nombre los roles otorgados para los cuales mostrar privilegios:

mysql> SHOW GRANTS FOR 'dev1'@'localhost' USING 'app_developer';
+----------------------------------------------------------+
| Grants for dev1@localhost                                |
+----------------------------------------------------------+
| GRANT USAGE ON *.* TO `dev1`@`localhost`                 |
| GRANT ALL PRIVILEGES ON `app_db`.* TO `dev1`@`localhost` |
| GRANT `app_developer`@`%` TO `dev1`@`localhost`          |
+----------------------------------------------------------+

Verifique cada otro tipo de usuario de manera similar:

mysql> SHOW GRANTS FOR 'read_user1'@'localhost' USING 'app_read';
+--------------------------------------------------------+
| Grants for read_user1@localhost                        |
+--------------------------------------------------------+
| GRANT USAGE ON *.* TO `read_user1`@`localhost`         |
| GRANT SELECT ON `app_db`.* TO `read_user1`@`localhost` |
| GRANT `app_read`@`%` TO `read_user1`@`localhost`       |
+--------------------------------------------------------+
mysql> SHOW GRANTS FOR 'rw_user1'@'localhost' USING 'app_read', 'app_write';
+------------------------------------------------------------------------------+
| Grants for rw_user1@localhost                                                |
+------------------------------------------------------------------------------+
| GRANT USAGE ON *.* TO `rw_user1`@`localhost`                                 |
| GRANT SELECT, INSERT, UPDATE, DELETE ON `app_db`.* TO `rw_user1`@`localhost` |
| GRANT `app_read`@`%`,`app_write`@`%` TO `rw_user1`@`localhost`               |
+------------------------------------------------------------------------------+

Activar roles

Los roles otorgados a una cuenta de usuario pueden estar activos o inactivos dentro de las sesiones de la cuenta. Si un rol concedido está activo dentro de una sesión, se aplican sus privilegios; de lo contrario, no lo hacen. Para determinar qué roles están activos dentro de la sesión actual, use la función [CURRENT_ROLE()].

De forma predeterminada, otorgar un rol a una cuenta o nombrarlo en el valor [mandatory_roles] de la variable del sistema no hace que el rol se active automáticamente dentro de las sesiones de la cuenta. Por ejemplo, debido a que hasta ahora en la discusión anterior (rw_user1) no se han activado roles, si se conecta al servidor como rw_user1 e invoca la función [CURRENT_ROLE()], el resultado es NONE(sin roles activos):

mysql> SELECT CURRENT_ROLE();
+----------------+
| CURRENT_ROLE() |
+----------------+
| NONE           |
+----------------+

Para especificar qué roles deben activarse cada vez que un usuario se conecta al servidor y se autentica, use [SET DEFAULT ROLE]. Para establecer el valor predeterminado para todos los roles asignados para cada cuenta creada anteriormente, use esta declaración:

SET DEFAULT ROLE ALL TO
  'dev1'@'localhost',
  'read_user1'@'localhost',
  'read_user2'@'localhost',
  'rw_user1'@'localhost';

Ahora, si se conecta como rw_user1, el valor inicial de [CURRENT_ROLE()] refleja las nuevas asignaciones de roles predeterminadas:

mysql> SELECT CURRENT_ROLE();
+--------------------------------+
| CURRENT_ROLE()                 |
+--------------------------------+
| `app_read`@`%`,`app_write`@`%` |
+--------------------------------+

Para que todos los roles obligatorios y otorgados explícitamente se activen automáticamente cuando los usuarios se conectan al servidor, habilite la variable [activate_all_roles_on_login] del sistema. De forma predeterminada, la activación automática de roles está deshabilitada.

Dentro de una sesión, un usuario puede ejecutar [SET ROLE] para cambiar el conjunto de roles activos. Por ejemplo, para rw_user1:

mysql> SET ROLE NONE; SELECT CURRENT_ROLE();
+----------------+
| CURRENT_ROLE() |
+----------------+
| NONE           |
+----------------+
mysql> SET ROLE ALL EXCEPT 'app_write'; SELECT CURRENT_ROLE();
+----------------+
| CURRENT_ROLE() |
+----------------+
| `app_read`@`%` |
+----------------+
mysql> SET ROLE DEFAULT; SELECT CURRENT_ROLE();
+--------------------------------+
| CURRENT_ROLE()                 |
+--------------------------------+
| `app_read`@`%`,`app_write`@`%` |
+--------------------------------+

Revocación de funciones o privilegios de funciones

Así como se pueden otorgar roles a una cuenta, se pueden revocar de una cuenta:

REVOKE role FROM user;

Los roles nombrados en el valor [mandatory_roles] de la variable del sistema no se pueden revocar.

[REVOKE] también se puede aplicar a un rol para modificar los privilegios que se le otorgan. Esto afecta no solo al rol en sí, sino a cualquier cuenta a la que se le otorgue ese rol. Suponga que desea hacer que todos los usuarios de la aplicación sean de solo lectura temporalmente. Para hacer esto, use [REVOKE] para revocar los privilegios de modificación del app_writerol:

REVOKE INSERT, UPDATE, DELETE ON app_db.* FROM 'app_write';

Da la casualidad de que eso deja al rol sin privilegios en absoluto, como se puede ver usando [SHOW GRANTS] (lo que demuestra que esta declaración se puede usar con roles, no solo con usuarios):

mysql> SHOW GRANTS FOR 'app_write';
+---------------------------------------+
| Grants for app_write@%                |
+---------------------------------------+
| GRANT USAGE ON *.* TO `app_write`@`%` |
+---------------------------------------+

Descartar roles

Para eliminar roles, use DROP ROLE:

DROP ROLE 'app_read', 'app_write';

Eliminar un rol lo revoca de todas las cuentas a las que se le otorgó.

Los roles nombrados en el valor [mandatory_roles] de la variable del sistema no se pueden descartar.

Asignación de contraseñas de cuenta

Las credenciales requeridas para los clientes que se conectan al servidor MySQL pueden incluir una contraseña. Esta sección describe cómo asignar contraseñas para cuentas MySQL.

MySQL almacena las credenciales en la tabla user de la bd mysql del sistema. Las operaciones que asignan o modifican contraseñas solo se permiten a los usuarios con [CREATE USER] o, alternativamente, privilegios para la bdmysql  ( [INSERT] para crear nuevas cuentas, [UPDATE] para modificar cuentas existentes). Si la variable del sistema [read_only] está habilitada, el uso de declaraciones de modificación de cuenta como [CREATE USER] o [ALTER USER] adicionalmente requiere el privilegio [CONNECTION_ADMIN] o el privilegio [SUPER].

Para asignar una contraseña cuando crea una nueva cuenta, use [CREATE USER] e incluya IDENTIFIED BY:

CREATE USER 'jeffrey'@'localhost' IDENTIFIED BY 'password';

[CREATE USER] también admite la sintaxis para especificar el complemento de autenticación de la cuenta.

Para asignar o cambiar una contraseña para una cuenta existente, use [ALTER USER] con IDENTIFIED BY:

ALTER USER 'jeffrey'@'localhost' IDENTIFIED BY 'password';

Si no está conectado como usuario anónimo, puede cambiar su propia contraseña sin nombrar su propia cuenta literalmente:

ALTER USER USER() IDENTIFIED BY 'password';

Para cambiar la contraseña de una cuenta desde la línea de comandos, use el [comando mysqladmin] :

mysqladmin -u user_name -h host_name password "password"

La cuenta para la que este comando establece la contraseña es la que tiene una fila en la tabla mysql.user que coincide user_name en la columna User y el client_host desde el cual se conecta en la columna Host.

Advertencia

Establecer una contraseña usando [mysqladmin] debe considerarse inseguro . En algunos sistemas, su contraseña se vuelve visible para los programas de estado del sistema, como ps, que pueden ser invocados por otros usuarios para mostrar líneas de comando. Los clientes de MySQL normalmente sobrescriben el argumento de la contraseña de la línea de comandos con ceros durante su secuencia de inicialización. Sin embargo, todavía hay un breve intervalo durante el cual el valor es visible. Además, en algunos sistemas esta estrategia de sobrescritura es ineficaz y la contraseña permanece visible para ps . (Los sistemas SystemV Unix y quizás otros están sujetos a este problema).

Gestión de contraseñas

A continuación se enumeran una serie de links donde se indican diferentes aspectos de l gestión de contraseñas.

Resolución de problemas de conexión a MySQL

Si encuentra problemas cuando intenta conectarse al servidor MySQL, los siguientes elementos describen algunos cursos de acción que puede tomar para corregir el problema.

  • Asegúrese de que el servidor esté funcionando. Si no es así, los clientes no pueden conectarse a él. Por ejemplo, si un intento de conectarse al servidor falla con un mensaje como uno de los siguientes, una de las causas podría ser que el servidor no se esté ejecutando:

    $> mysql
ERROR 2003: Can't connect to MySQL server on 'host_name' (111)
$> mysql
ERROR 2002: Can't connect to local MySQL server through socket
'/tmp/mysql.sock' (111)

  • Puede ser que el servidor se esté ejecutando, pero usted está intentando conectarse utilizando un puerto TCP / IP, una canalización con nombre o un archivo de socket Unix diferente del que está escuchando el servidor. Para corregir esto cuando invoca un programa cliente, especifique una opción [--port] para indicar el número de puerto adecuado, o una opción [--socket] para indicar la tubería con nombre adecuado o el archivo de socket Unix. Para saber dónde está el archivo de socket, puede usar este comando:

    $> netstat -ln | grep mysql

  • Asegúrese de que el servidor no se haya configurado para ignorar las conexiones de red o (si está intentando conectarse de forma remota) que no se haya configurado para escuchar solo localmente en sus interfaces de red. Si el servidor se inició con la [bind_address] establecida en 127.0.0.1, escucha las conexiones TCP / IP solo localmente en la interfaz de bucle invertido y no acepta conexiones remotas.

  • Verifique para asegurarse de que no haya un firewall que bloquee el acceso a MySQL. Su firewall puede configurarse según la aplicación que se esté ejecutando o el número de puerto utilizado por MySQL para la comunicación (3306 por defecto). En Linux o Unix, verifique la configuración de sus tablas de IP (o similar) para asegurarse de que el puerto no haya sido bloqueado. En Windows, es posible que sea necesario configurar aplicaciones como ZoneAlarm o Firewall de Windows para que no bloqueen el puerto MySQL.

  • Después de una instalación nueva, si intenta iniciar sesión en el servidor root sin utilizar una contraseña, es posible que reciba el siguiente mensaje de error.

    $> mysql -u root
ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO)

    Significa que ya se ha asignado una contraseña de root durante la instalación y debe proporcionarse. Consulte la Sección 2.10.4, "Cómo proteger la cuenta inicial de MySQL" para conocer las diferentes formas en que se pudo haber asignado la contraseña y, en algunos casos, cómo encontrarla. Si necesita restablecer la contraseña de root, consulte las instrucciones en la Sección B.3.3.2, "Cómo restablecer la contraseña de root" . Una vez que haya encontrado o restablecido su contraseña, inicie sesión nuevamente rootusando la opción --password(o -p):

    $> mysql -u root -p
Enter password:

    Sin embargo, el servidor le permitirá conectarse rootsin usar una contraseña si ha inicializado MySQL usando mysqld --initialize-insecure (consulte la Sección 2.10.1, "Inicialización del directorio de datos" para obtener más detalles). Eso es un riesgo de seguridad, por lo que debe establecer una contraseña para la rootcuenta; consulte la Sección 2.10.4, "Protección de la cuenta MySQL inicial" para obtener instrucciones.

  • Si ha actualizado una instalación de MySQL existente a una versión más reciente, ¿realizó el procedimiento de actualización de MySQL? Si no es así, hágalo. La estructura de las tablas de subvenciones cambia ocasionalmente cuando se agregan nuevas capacidades, por lo que después de una actualización siempre debe asegurarse de que sus tablas tengan la estructura actual.

  • Si un programa cliente recibe el siguiente mensaje de error cuando intenta conectarse, significa que el servidor espera contraseñas en un formato más nuevo que el que el cliente es capaz de generar:

    $> mysql
Client does not support authentication protocol requested
by server; consider upgrading MySQL client

  • Recuerde que los programas cliente utilizan parámetros de conexión especificados en archivos de opciones o variables de entorno. Si un programa cliente parece estar enviando parámetros de conexión predeterminados incorrectos cuando no los ha especificado en la línea de comandos, verifique los archivos de opciones aplicables y su entorno. Por ejemplo, si obtiene Access deniedcuando ejecuta un cliente sin ninguna opción, asegúrese de no haber especificado una contraseña anterior en ninguno de sus archivos de opciones.

    Puede suprimir el uso de archivos de opciones por parte de un programa cliente invocándolo con la [--no-defaults]. Por ejemplo:

    $> mysqladmin --no-defaults -u root version

  • Si recibe el siguiente error, significa que está utilizando una contraseña root incorrecta:

    $> mysqladmin -u root -pxxxx ver
Access denied for user 'root'@'localhost' (using password: YES)

    Si el error anterior ocurre incluso cuando no ha especificado una contraseña, significa que tiene una contraseña incorrecta en algún archivo de opciones. Pruebe la [--no-defaults] como se describe en el artículo anterior.

    Si ha perdido u olvidado la root contraseña, consulte la Sección B.3.3.2, "Cómo restablecer la contraseña de root" .

  • localhost es un sinónimo de su nombre de host local y también es el host predeterminado al que los clientes intentan conectarse si no especifica ningún host explícitamente.

  • El mensaje Access denied de error le indica con quién está intentando iniciar sesión, el host del cliente desde el que está intentando conectarse y si estaba utilizando una contraseña. Normalmente, debe tener una fila en la usertabla que coincida exactamente con el nombre de host y el nombre de usuario que se proporcionaron en el mensaje de error. Por ejemplo, si recibe un mensaje de error que contiene using password: NO, significa que intentó iniciar sesión sin una contraseña.

  • Si obtiene un error Access denied al intentar conectarse a la base de datos con , es posible que tenga un problema con la tabla. Verifique esto ejecutando y emitiendo esta declaración SQL: mysql -u *user_name*``user``mysql -u root mysql

    SELECT * FROM user;

    El resultado debe incluir una fila con las columnas Hosty Userque coincidan con el nombre de host de su cliente y su nombre de usuario de MySQL.

  • Si se produce el siguiente error cuando intenta conectarse desde un host que no sea aquel en el que se está ejecutando el servidor MySQL, significa que no hay una fila en la tabla user con un valor Host que coincida con el host del cliente:

    Host ... is not allowed to connect to this MySQL server

    Puede solucionar este problema configurando una cuenta para la combinación de nombre de host del cliente y nombre de usuario que está utilizando al intentar conectarse.

    Si no conoce la dirección IP o el nombre de host de la máquina desde la que se está conectando, debe colocar una fila con '%'el vaor Host de la columna en la tabla user. Después de intentar conectarse desde la máquina cliente, utilice una SELECT USER()consulta para ver cómo se conectó realmente. Luego, cambie el '%'en la userfila de la tabla al nombre de host real que aparece en el registro. De lo contrario, su sistema queda inseguro porque permite conexiones desde cualquier host para el nombre de usuario dado.

    En Linux, otra razón por la que puede ocurrir este error es que está usando una versión binaria de MySQL que está compilada con una versión diferente de la biblioteca glibc que la que está usando. En este caso, debe actualizar su sistema operativo glibc o descargar una distribución fuente de la versión de MySQL y compilarla usted mismo. Normalmente, la compilación e instalación de un RPM de origen es trivial, por lo que este no es un gran problema.

  • Si especifica un nombre de host al intentar conectarse, pero obtiene un mensaje de error donde el nombre de host no se muestra o es una dirección IP, significa que el servidor MySQL recibió un error al intentar resolver la dirección IP del host del cliente a un nombre:

    $> mysqladmin -u root -pxxxx -h some_hostname ver
Access denied for user 'root'@'' (using password: YES)

    Si intenta conectarse como root y obtiene el siguiente error, significa que no tiene una fila en la tabla usertabla con un valor User de columna de 'root' y que [mysqld] no puede resolver el nombre de host para su cliente:

    Access denied for user ''@'unknown'

    Estos errores indican un problema de DNS. Para solucionarlo, ejecute [mysqladmin flush-hosts] para restablecer la caché del host DNS interno.