Ejemplo de GRANT de Mariadb

Sintaxis

GRANT
    priv_type [(column_list)]
      [, priv_type [(column_list)]] ...
    ON [object_type] priv_level
    TO user_specification [ user_options ...]

user_specification:
  username [authentication_option]

authentication_option:
  IDENTIFIED BY 'password' 
  | IDENTIFIED BY PASSWORD 'password_hash'
  | IDENTIFIED {VIA|WITH} authentication_rule [OR authentication_rule  ...]

authentication_rule:
    authentication_plugin
  | authentication_plugin {USING|AS} 'authentication_string'
  | authentication_plugin {USING|AS} PASSWORD('password')

GRANT PROXY ON username
    TO username [, username] ...
    [WITH GRANT OPTION]

user_options:
    [REQUIRE {NONE | tls_option [[AND] tls_option] ...}]
    [WITH with_option [with_option] ...]

object_type:
    TABLE
  | FUNCTION
  | PROCEDURE

priv_level:
    *
  | *.*
  | db_name.*
  | db_name.tbl_name
  | tbl_name
  | db_name.routine_name

with_option:
    GRANT OPTION
  | resource_option

resource_option:
  MAX_QUERIES_PER_HOUR count
  | MAX_UPDATES_PER_HOUR count
  | MAX_CONNECTIONS_PER_HOUR count
  | MAX_USER_CONNECTIONS count
  | MAX_STATEMENT_TIME time

tls_option:
  SSL 
  | X509
  | CIPHER 'cipher'
  | ISSUER 'issuer'
  | SUBJECT 'subject'

Descripción

los GRANT La declaración le permite otorgar privilegios o roles a las cuentas. Usar GRANT, debes tener el GRANT OPTION privilegio, y debe tener los privilegios que está otorgando.

Utilizar el REVOKE declaración para revocar los privilegios otorgados con el GRANT declaración.

Utilizar el SHOW GRANTS declaración para determinar qué privilegios tiene una cuenta.

Nombres de cuenta

Para GRANT extractos, los nombres de las cuentas se especifican como username argumento de la misma manera que lo son para CREATE USER declaraciones. Ver nombres de cuentas del CREATE USER página para obtener detalles sobre cómo se especifican los nombres de cuenta.

Creación de cuenta implícita

los GRANT La declaración también le permite crear cuentas implícitamente en algunos casos.

Si la cuenta aún no existe, entonces GRANT implícitamente puede crearlo. Para crear implícitamente una cuenta con GRANT, se requiere que un usuario tenga los mismos privilegios que se requerirían para crear explícitamente la cuenta con el CREATE USER declaración.

Si el NO_AUTO_CREATE_USER SQL_MODE está configurada, las cuentas solo se pueden crear si se especifica la información de autenticación, o con un CREATE USER declaración. Si no se proporciona información de autenticación, GRANT producirá un error cuando la cuenta especificada no existe, por ejemplo:

show variables like '%sql_mode%' ;
+---------------+--------------------------------------------+
| Variable_name | Value                                      |
+---------------+--------------------------------------------+
| sql_mode      | NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION |
+---------------+--------------------------------------------+

GRANT USAGE ON *.* TO 'user123'@'%' IDENTIFIED BY '';
ERROR 1133 (28000): Can't find any matching row in the user table

GRANT USAGE ON *.* TO 'user123'@'%' IDENTIFIED VIA PAM using 'mariadb' require ssl ;
Query OK, 0 rows affected (0.00 sec)
 
select host, user from mysql.user where user="user123" ;

+------+----------+
| host | user     |
+------+----------+
| %    | user123 |
+------+----------+

Niveles de privilegio

Los privilegios se pueden establecer globalmente, para una base de datos completa, para una tabla o rutina, o para columnas individuales en una tabla. Ciertos privilegios solo se pueden establecer en ciertos niveles.

• Los privilegios globales se otorgan mediante *.* por priv_level. Los privilegios globales incluyen privilegios para administrar la base de datos y administrar cuentas de usuario, así como privilegios para todas las tablas, funciones y procedimientos. Los privilegios globales se almacenan en el mysql.user table.

• Los privilegios de la base de datos se otorgan mediante db_name.* por priv_level, o usando solo * para utilizar la base de datos predeterminada. Los privilegios de la base de datos incluyen privilegios para crear tablas y funciones, así como privilegios para todas las tablas, funciones y procedimientos de la base de datos. Los privilegios de la base de datos se almacenan en el mysql.db table.

• Los privilegios de mesa se otorgan mediante db_name.tbl_name por priv_level, o usando solo tbl_name para especificar una tabla en la base de datos predeterminada. los TABLE la palabra clave es opcional. Los privilegios de la tabla incluyen la capacidad de seleccionar y cambiar datos en la tabla. Se pueden otorgar ciertos privilegios de tabla para columnas individuales.

• Los privilegios de columna se otorgan especificando una tabla para priv_level y proporcionar una lista de columnas después del tipo de privilegio. Le permiten controlar exactamente qué columnas de una tabla pueden seleccionar y cambiar los usuarios.

• Los privilegios de función se otorgan mediante FUNCTION db_name.routine_name por priv_level, o usando solo FUNCTION routine_name para especificar una función en la base de datos predeterminada.

• Los privilegios de procedimiento se otorgan mediante PROCEDURE db_name.routine_name por priv_level, o usando solo PROCEDURE routine_name para especificar un procedimiento en la base de datos predeterminada.

los USAGE Privilegio

los USAGE privilegio no otorga privilegios reales. los SHOW GRANTS declaración mostrará un global USAGE privilegio para un usuario recién creado. Puedes usar USAGE con el GRANT declaración para cambiar opciones como GRANT OPTION y MAX_USER_CONNECTIONS sin cambiar los privilegios de la cuenta.

los ALL PRIVILEGES Privilegio

los ALL PRIVILEGES privilege concede todos los privilegios disponibles. La concesión de todos los privilegios solo afecta al nivel de privilegio dado. Por ejemplo, otorgar todos los privilegios en una tabla no otorga ningún privilegio en la base de datos o globalmente.

Utilizando ALL PRIVILEGES no otorga el especial GRANT OPTION privilegio.

Puedes usar ALL en lugar de ALL PRIVILEGES.

los GRANT OPTION Privilegio

Utilizar el WITH GRANT OPTION cláusula para dar a los usuarios la capacidad de otorgar privilegios a otros usuarios en el nivel de privilegio dado. Usuarios con GRANT OPTION privilege solo puede otorgar los privilegios que tienen. No pueden otorgar privilegios a un nivel de privilegio superior al que tienen GRANT OPTION privilegio.

los GRANT OPTION el privilegio no se puede establecer para columnas individuales. Si utiliza WITH GRANT OPTION al especificar privilegios de columna, el GRANT OPTION Se otorgará privilegio para toda la mesa.

Utilizando el WITH GRANT OPTION la cláusula es equivalente a listar GRANT OPTION como un privilegio.

Privilegios globales

La siguiente tabla enumera los privilegios que se pueden otorgar globalmente. También puede otorgar todos los privilegios de base de datos, tablas y funciones de forma global. Cuando se otorgan globalmente, estos privilegios se aplican a todas las bases de datos, tablas o funciones, incluidas las creadas posteriormente.

Para establecer un privilegio global, use *.* por priv_level.

Privilegios de base de datos

La siguiente tabla enumera los privilegios que se pueden otorgar a nivel de base de datos. También puede otorgar todos los privilegios de tabla y función en el nivel de la base de datos. Los privilegios de tabla y función en una base de datos se aplican a todas las tablas o funciones de esa base de datos, incluidas las creadas posteriormente.

Para establecer un privilegio para una base de datos, especifique la base de datos usando db_name.* por priv_level, o simplemente usa * para especificar la base de datos predeterminada.

Privilegios de mesa

Privilegios de columna

Se pueden establecer algunos privilegios de tabla para columnas individuales de una tabla. Para usar privilegios de columna, especifique la tabla explícitamente y proporcione una lista de nombres de columna después del tipo de privilegio. Por ejemplo, la siguiente declaración permitiría al usuario leer los nombres y puestos de los empleados, pero no otra información de la misma tabla, como los salarios.

GRANT SELECT (name, position) on Employee to 'jeffrey'@'localhost';

Privilegios de función

Privilegios de procedimiento

Privilegios de proxy

los PROXY El privilegio permite que un usuario actúe como proxy como otro usuario, lo que significa que sus privilegios cambian a los del usuario proxy, y el CURRENT_USER() La función devuelve el nombre de usuario del usuario proxy.

los PROXY privilege solo funciona con complementos de autenticación que lo admitan. El valor por defecto mysql_native_password El complemento de autenticación no admite usuarios proxy.

los pam El complemento de autenticación es el único incluido con MariaDB que actualmente admite usuarios proxy. los PROXY privilegio se usa comúnmente con el pam complemento de autenticación para habilitar el mapeo de usuarios y grupos con PAM.

Por ejemplo, para otorgar la PROXY privilegio a una cuenta anónima que se autentica con el pam complemento de autenticación, puede ejecutar lo siguiente:

CREATE USER 'dba'@'%' IDENTIFIED BY 'strongpassword';
GRANT ALL PRIVILEGES ON *.* TO 'dba'@'%' ;

CREATE USER ''@'%' IDENTIFIED VIA pam USING 'mariadb';
GRANT PROXY ON 'dba'@'%' TO ''@'%';

Una cuenta de usuario solo puede otorgar PROXY privilegio para una cuenta de usuario específica si el otorgante también tiene el PROXY privilegio para esa cuenta de usuario específica, y si ese privilegio está definido WITH GRANT OPTION. Por ejemplo, el siguiente ejemplo falla porque el otorgante no tiene el PROXY privilegio para esa cuenta de usuario específica en absoluto:

SELECT USER(), CURRENT_USER();
+-----------------+-----------------+
| USER()          | CURRENT_USER()  |
+-----------------+-----------------+
| alice@localhost | alice@localhost |
+-----------------+-----------------+

SHOW GRANTS;
+-----------------------------------------------------------------------------------------------------------------------+
| Grants for alice@localhost                                                                                            |
+-----------------------------------------------------------------------------------------------------------------------+
| GRANT ALL PRIVILEGES ON *.* TO 'alice'@'localhost' IDENTIFIED BY PASSWORD '*2470C0C06DEE42FD1618BB99005ADCA2EC9D1E19' |
+-----------------------------------------------------------------------------------------------------------------------+

GRANT PROXY ON 'dba'@'localhost' TO 'bob'@'localhost';
ERROR 1698 (28000): Access denied for user 'alice'@'localhost'

Y el siguiente ejemplo falla porque el otorgante tiene el PROXY privilegio para esa cuenta de usuario específica, pero no está definido WITH GRANT OPTION:

SELECT USER(), CURRENT_USER();
+-----------------+-----------------+
| USER()          | CURRENT_USER()  |
+-----------------+-----------------+
| alice@localhost | alice@localhost |
+-----------------+-----------------+

SHOW GRANTS;
+-----------------------------------------------------------------------------------------------------------------------+
| Grants for alice@localhost                                                                                            |
+-----------------------------------------------------------------------------------------------------------------------+
| GRANT ALL PRIVILEGES ON *.* TO 'alice'@'localhost' IDENTIFIED BY PASSWORD '*2470C0C06DEE42FD1618BB99005ADCA2EC9D1E19' |
| GRANT PROXY ON 'dba'@'localhost' TO 'alice'@'localhost'                                                               |
+-----------------------------------------------------------------------------------------------------------------------+

MariaDB [(none)]> GRANT PROXY ON 'dba'@'localhost' TO 'bob'@'localhost';
ERROR 1698 (28000): Access denied for user 'alice'@'localhost'

Pero el siguiente ejemplo tiene éxito porque el otorgante tiene la PROXY privilegio para esa cuenta de usuario específica, y se define WITH GRANT OPTION:

SELECT USER(), CURRENT_USER();
+-----------------+-----------------+
| USER()          | CURRENT_USER()  |
+-----------------+-----------------+
| alice@localhost | alice@localhost |
+-----------------+-----------------+

SHOW GRANTS;
+-----------------------------------------------------------------------------------------------------------------------------------------+
| Grants for alice@localhost                                                                                                              |
+-----------------------------------------------------------------------------------------------------------------------------------------+
| GRANT ALL PRIVILEGES ON *.* TO 'alice'@'localhost' IDENTIFIED BY PASSWORD '*2470C0C06DEE42FD1618BB99005ADCA2EC9D1E19' WITH GRANT OPTION |
| GRANT PROXY ON 'dba'@'localhost' TO 'alice'@'localhost' WITH GRANT OPTION                                                               |
+-----------------------------------------------------------------------------------------------------------------------------------------+

GRANT PROXY ON 'dba'@'localhost' TO 'bob'@'localhost';
Query OK, 0 rows affected (0.004 sec)

Una cuenta de usuario puede otorgar PROXY privilegio para cualquier otra cuenta de usuario si el otorgante tiene el PROXY privilegio para el ''@'%' cuenta de usuario anónimo, así:

GRANT PROXY ON ''@'%' TO 'dba'@'localhost' WITH GRANT OPTION;

Por ejemplo, el siguiente ejemplo tiene éxito porque el usuario puede otorgar la PROXY privilegio para cualquier otra cuenta de usuario:

SELECT USER(), CURRENT_USER();
+-----------------+-----------------+
| USER()          | CURRENT_USER()  |
+-----------------+-----------------+
| alice@localhost | alice@localhost |
+-----------------+-----------------+

SHOW GRANTS;
+-----------------------------------------------------------------------------------------------------------------------------------------+
| Grants for alice@localhost                                                                                                              |
+-----------------------------------------------------------------------------------------------------------------------------------------+
| GRANT ALL PRIVILEGES ON *.* TO 'alice'@'localhost' IDENTIFIED BY PASSWORD '*2470C0C06DEE42FD1618BB99005ADCA2EC9D1E19' WITH GRANT OPTION |
| GRANT PROXY ON ''@'%' TO 'alice'@'localhost' WITH GRANT OPTION                                                                          |
+-----------------------------------------------------------------------------------------------------------------------------------------+

GRANT PROXY ON 'app1_dba'@'localhost' TO 'bob'@'localhost';
Query OK, 0 rows affected (0.004 sec)

GRANT PROXY ON 'app2_dba'@'localhost' TO 'carol'@'localhost';
Query OK, 0 rows affected (0.004 sec)

El valor por defecto root cuentas de usuario creadas por mysql_install_db tener este privilegio. Por ejemplo:

GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' WITH GRANT OPTION;
GRANT PROXY ON ''@'%' TO 'root'@'localhost' WITH GRANT OPTION;

Esto permite que el valor predeterminado root cuentas de usuario para otorgar el PROXY privilegio para cualquier otra cuenta de usuario, y también permite el root cuentas de usuario para otorgar a otros el privilegio de hacer lo mismo.

Opciones de autenticación

Las opciones de autenticación para el GRANT declaración son los mismos que los de la CREATE USER declaración.

IDENTIFICADO POR ‘contraseña’

El opcional IDENTIFIED BY La cláusula se puede utilizar para proporcionar una cuenta con una contraseña. La contraseña debe especificarse en texto sin formato. Será hash por el PASSWORD función antes de ser almacenado en el mysql.user mesa.

Por ejemplo, si nuestra contraseña es mariadb, luego podemos crear el usuario con:

GRANT USAGE ON *.* TO foo2@test IDENTIFIED BY 'mariadb';

Si no especifica una contraseña con el IDENTIFIED BY cláusula, el usuario podrá conectarse sin contraseña. Una contraseña en blanco no es un comodín para coincidir con ninguna contraseña. El usuario debe conectarse sin proporcionar una contraseña si no se establece ninguna contraseña.

Si la cuenta de usuario ya existe y si proporciona la IDENTIFIED BY cláusula, se cambiará la contraseña del usuario. Debe tener los privilegios necesarios para SET PASSWORD declaración para cambiar la contraseña de un usuario con GRANT.

Los únicos complementos de autenticación que admite esta cláusula son mysql_native_password y mysql_old_password.

IDENTIFICADO POR CONTRASEÑA ‘password_hash’

El opcional IDENTIFIED BY PASSWORD La cláusula se puede utilizar para proporcionar una cuenta con una contraseña que ya ha sido codificada. La contraseña debe especificarse como un hash proporcionado por el PASSWORD función. Se almacenará en el mysql.user tabla como está.

Por ejemplo, si nuestra contraseña es mariadb, luego podemos encontrar el hash con:

SELECT PASSWORD('mariadb');
+-------------------------------------------+
| PASSWORD('mariadb')                       |
+-------------------------------------------+
| *54958E764CE10E50764C2EECBB71D01F08549980 |
+-------------------------------------------+
1 row in set (0.00 sec)

Y luego podemos crear un usuario con el hash:

GRANT USAGE ON *.* TO foo2@test IDENTIFIED BY PASSWORD '*54958E764CE10E50764C2EECBB71D01F08549980';

Si no especifica una contraseña con el IDENTIFIED BY cláusula, el usuario podrá conectarse sin contraseña. Una contraseña en blanco no es un comodín para coincidir con ninguna contraseña. El usuario debe conectarse sin proporcionar una contraseña si no se establece ninguna contraseña.

Si la cuenta de usuario ya existe y si proporciona la IDENTIFIED BY cláusula, se cambiará la contraseña del usuario. Debe tener los privilegios necesarios para SET PASSWORD declaración para cambiar la contraseña de un usuario con GRANT.

Los únicos complementos de autenticación que admite esta cláusula son mysql_native_password y mysql_old_password.

IDENTIFICADO {VIA | WITH} authentication_plugin

El opcional IDENTIFIED VIA authentication_plugin le permite especificar que la cuenta debe ser autenticada por un complemento de autenticación específico. El nombre del complemento debe ser un complemento de autenticación activo según SHOW PLUGINS. Si no aparece en esa salida, deberá instalarlo con INSTALL PLUGIN o INSTALL SONAME.

Por ejemplo, esto podría usarse con el complemento de autenticación PAM:

GRANT USAGE ON *.* TO foo2@test IDENTIFIED VIA pam;

Algunos complementos de autenticación permiten especificar argumentos adicionales después de una USING o AS palabra clave. Por ejemplo, el complemento de autenticación PAM acepta un nombre de servicio:

GRANT USAGE ON *.* TO foo2@test IDENTIFIED VIA pam USING 'mariadb';

El significado exacto del argumento adicional dependería del complemento de autenticación específico.

MariaDB comenzando con 10.4.0

los USING o AS La palabra clave también se puede utilizar para proporcionar una contraseña de texto sin formato a un complemento si se proporciona como un argumento para la función PASSWORD (). Esto solo es válido para complementos de autenticación que han implementado un enlace para la función PASSWORD (). Por ejemplo, el ed25519 El complemento de autenticación admite esto:

CREATE USER safe@'%' IDENTIFIED VIA ed25519 USING PASSWORD('secret');

MariaDB comenzando con 10.4.3

Se pueden especificar muchos complementos de autenticación, todos funcionan como formas alternativas de autenticar a un usuario:

CREATE USER safe@'%' IDENTIFIED VIA ed25519 USING PASSWORD('secret') OR unix_socket;

Opciones de límite de recursos

MariaDB comenzando con 10.2.0

MariaDB 10.2.0 introdujo una serie de opciones de límite de recursos.

Es posible establecer límites por cuenta para ciertos recursos del servidor. La siguiente tabla muestra los valores que se pueden establecer por cuenta:

Si alguno de estos límites se establece en 0, entonces no hay límite para ese recurso para ese usuario.

Para establecer límites de recursos para una cuenta, si no desea cambiar los privilegios de esa cuenta, puede emitir un GRANT declaración con el USAGE privilegio, que no tiene sentido. La declaración puede nombrar algunos o todos los tipos de límites, en cualquier orden.

A continuación, se muestra un ejemplo que muestra cómo establecer límites de recursos:

GRANT USAGE ON *.* TO 'someone'@'localhost' WITH
    MAX_USER_CONNECTIONS 0
    MAX_QUERIES_PER_HOUR 200;

Los recursos se rastrean por cuenta, lo que significa 'user'@'server'; no por nombre de usuario o por conexión.

El recuento se puede restablecer para todos los usuarios que utilizan FLUSH USER_RESOURCES, FLUSH PRIVILEGES o mysqladmin reload.

Los límites de recursos por cuenta se almacenan en el user mesa, en el mysql base de datos. Las columnas utilizadas para los límites de recursos se nombran max_questions, max_updates, max_connections (por MAX_CONNECTIONS_PER_HOUR), y max_user_connections (por MAX_USER_CONNECTIONS).

Opciones de TLS

De forma predeterminada, MariaDB transmite datos entre el servidor y los clientes sin cifrarlos. Esto es generalmente aceptable cuando el servidor y el cliente se ejecutan en el mismo host o en redes donde la seguridad está garantizada por otros medios. Sin embargo, en los casos en que el servidor y el cliente existen en redes separadas o están en una red de alto riesgo, la falta de cifrado introduce problemas de seguridad, ya que un actor malintencionado podría espiar el tráfico a medida que se envía a través de la red entre ellos. .

Para mitigar esta preocupación, MariaDB le permite cifrar los datos en tránsito entre el servidor y los clientes mediante el protocolo Transport Layer Security (TLS). TLS se conocía anteriormente como Secure Socket Layer (SSL), pero estrictamente hablando, el protocolo SSL es un predecesor de TLS y esa versión del protocolo ahora se considera insegura. La documentación todavía usa el término SSL a menudo y, por razones de compatibilidad, el sistema de servidor relacionado con TLS y las variables de estado aún usan el prefijo ssl_, pero internamente, MariaDB solo admite sus sucesores seguros.

Consulte Descripción general de conexiones seguras para obtener más información sobre cómo determinar si su servidor MariaDB tiene soporte TLS.

Puede establecer ciertas restricciones relacionadas con TLS para cuentas de usuario específicas. Por ejemplo, puede usar esto con cuentas de usuario que requieren acceso a datos confidenciales mientras los envían a través de redes que no controla. Estas restricciones se pueden habilitar para una cuenta de usuario con el CREATE USER, ALTER USER, o GRANT declaraciones. Las siguientes opciones están disponibles:

los REQUIRE La palabra clave debe usarse solo una vez para todas las opciones especificadas, y la palabra clave AND La palabra clave se puede utilizar para separar opciones individuales, pero no es necesaria.

Por ejemplo, puede crear una cuenta de usuario que requiera estas opciones de TLS con lo siguiente:

GRANT USAGE ON *.* TO 'alice'@'%'
    REQUIRE SUBJECT '/CN=alice/O=My Dom, Inc./C=US/ST=Oregon/L=Portland'
    AND ISSUER '/C=FI/ST=Somewhere/L=City/ O=Some Company/CN=Peter Parker/[email protected]'
    AND CIPHER 'TLSv1.2';

Si alguna de estas opciones está configurada para una cuenta de usuario específica, entonces cualquier cliente que intente conectarse con esa cuenta de usuario deberá estar configurado para conectarse con TLS.

Consulte Protección de las conexiones para el cliente y el servidor para obtener información sobre cómo habilitar TLS en el cliente y el servidor.

Roles

MariaDB comenzando con 10.0.5

Los roles se introdujeron en MariaDB 10.0.5.

Sintaxis

GRANT role TO grantee [, grantee2 ... ]
[ WITH ADMIN OPTION ]

La declaración GRANT también se utiliza para otorgar al uso un rol a uno o más usuarios u otros roles. Para poder otorgar un rol, el otorgante que lo haga debe tener permiso para hacerlo (ver CON ADMINISTRADOR en el artículo CREAR PAPEL).

Especificando el WITH ADMIN OPTION permite que el beneficiario, a su vez, otorgue el rol a otro.

Por ejemplo, los siguientes comandos muestran cómo otorgar el mismo rol a un par de usuarios diferentes.

GRANT journalist TO hulda;

GRANT journalist TO berengar WITH ADMIN OPTION;

Si a un usuario se le ha otorgado un rol, no obtiene automáticamente todos los permisos asociados con ese rol. Estos permisos solo se utilizan cuando el usuario activa el rol con la instrucción SET ROLE.

Ejemplos de subvenciones

Otorgar privilegios similares a los de la raíz

Puede crear un usuario que tenga privilegios similares a los predeterminados root cuentas ejecutando lo siguiente:

CREATE USER 'alexander'@'localhost';
GRANT ALL PRIVILEGES ON  *.* to 'alexander'@'localhost' WITH GRANT OPTION;

Ver también

• –skip-grant-tables le permite iniciar MariaDB sin GRANT. Esto es útil si perdió su contraseña de root.

• CREAR USUARIO

• ALTER USUARIO

• SOLICITAR USUARIO

• CONFIGURAR LA CLAVE

• MOSTRAR CREAR USUARIO

• tabla mysql.user

• Complementos de validación de contraseñas: permite establecer criterios básicos para las contraseñas.

• Complementos de autenticación: permiten utilizar varios métodos de autenticación y desarrollar otros nuevos.

El contenido reproducido en este sitio es propiedad de sus respectivos dueños, y MariaDB no revisa este contenido con anticipación. Los puntos de vista, la información y las opiniones expresadas por este contenido no representan necesariamente las de MariaDB o de cualquier otra parte.