Mostrando entradas con la etiqueta GRANT. Mostrar todas las entradas
Mostrando entradas con la etiqueta GRANT. Mostrar todas las entradas

sábado, 7 de diciembre de 2013

ERROR 1356 (HY000)

Original post:  http://anothermysqldba.blogspot.com/2013/12/error-1356-hy000.html


Lo más importante de entender cuando viene sobre un error es tomar un momento y relajarse. 
A veces la gente se encuentra con un error y se vuelven nerviosos y frustrados. Tome una respiración profunda y relajarse. A veces, " La locura es como la gravedad. Todo lo que necesita es un poco de empuje "y" A veces las preguntas son complicadas y las respuestas son simples . " 

¿Qué es todo esto? Bueno, por ejemplo, se me pidió recientemente para ayudar a resolver un problema que preocupaba otra DBA. Nada significaba en la falta de respeto a todos a que DBA pero estar en un pueblo de acometidas apenas dan a la respuesta que está en frente de ellos y en lugar de espiral hacia abajo en la locura . 

Este es el concepto general de la situación. 

Después de hacer un mysqldump de una base de datos que el usuario se mudó a otra base de datos para que otros puedan ser pruebas. La importación funcionaba bien. Sin embargo, los usuarios comenzaron a aparecer errores al tratar de consultar desde un punto de vista pre-compilados. 

mysql> select * from límite <nombre_vista> 1; 

ERROR 1356 (HY000): View '. <nombre_bd> <viewname>' Referencias mesa (s) inválida o columna (s) o la función (s) o definidor / invocador de vista de los derechos carecen de usarlos 

La primera reacción fue pensar que el que algo salió mal con la importación. Hizo la vista o en realidad las tablas relacionadas se corrompen? 

No. 

Para solucionar este error lo primero que TODO era: mysql> SHOW CREATE vista <nombre_vista> \ G 

Es probable que vea algo que comienza así: 
*************************** 1. fila *************************** 
Vista: Visitantes 
 
Crear vista: CREATE ALGORITMO = DEFINER UNDEFINED = `<Some_user>` @ `<Some_host_or_IP>` SQL SECURITY DEFINER VISTA 

Después de ver que el definidor es: `<Some_user>` @ `<Some_host_or_IP>` que puedas ver las subvenciones para ese usuario. 

mysql> SHOW GRANTS para `<Some_user>` @ `<Some_host_or_IP>`; 

Resulta que la solución era sólo lo que dijo el error en el primer lugar: "definidor / invocador de los derechos de vista la falta usarlos" 

Para hacer más fácil que usted puede hacer un show subvenciones en la base de datos en el que ya trabaja y copiar la instrucción de concesión, o puede revisar qué tipo de permisos que necesita para implementar en la nueva base de datos para que el fin de reunir los datos necesarios. 

Una simple actualización de los permisos para el usuario y el error se había ido. 

" A veces las respuestas son sencillas . " 


domingo, 19 de mayo de 2013

Los usuarios de MySQL :: Becas :: mysql_config_editor :: Seguridad

Original post: http://anothermysqldba.blogspot.com/2013/05/mysql-users-grants-mysqlconfigeditor.html

El acceso seguro a la base de datos es probable que la prioridad número uno para cualquier administrador de base de datos. Si no es así, entonces usted necesita considerar seriamente por qué no lo es. 

Las pautas generales a través del manual ya están disponibles: 


Uno de los principales problemas con la seguridad en MySQL es, por supuesto, los permisos que se ofrecen a los usuarios. 
Estas son algunas pautas simples. 

En primer lugar mantener "super usuario" o cuentas "root" al mínimo. Un usuario con acceso completo o "GRANT ALL" todavía tendrá acceso cuando haya alcanzado sus conexiones máx.Así que lo último que querría es un programa que va a ejecutar comandos con un usuario con acceso completo. 

Tenga en cuenta qué tipos de cuentas que está creando. Usted puede limitar a un usuarioMAX CONSULTAS, MAX, MAX ACTUALIZACIONES conexiones y MAX conexiones de usuario por hora . 

Tenga en cuenta el entorno de red que los usuarios se conectan desde. Si los usuarios van a utilizar direcciones de red DHCP en la misma subred que sólo sería la creación de más trabajo para ti si les limitado a una sola dirección IP. Todavía les puede limitar a la subred aunque con un comodín. Por ejemplo '192 .168.0.2 "versus '192 .168.0.% ' 

Manténgase alejado de todo acceso comodín para el host y los usuarios. 



> CREATE USER ''@'192.168.0.56' ;
Query OK, 0 rows affected (0.02 sec)

> show grants for ''@'192.168.0.56';
+-----------------------------------------+
| Grants for @192.168.0.56 |
+-----------------------------------------+
| GRANT USAGE ON *.* TO ''@'192.168.0.56' |
+-----------------------------------------+


Esto dejará abierta para cualquier persona de 192.168.0.56 y no es una cosa segura inteligente. 
También podría violar otras cuentas desde 192.168.0.56 ya que MySQL comprueba anfitrión primero y segundo nombre de usuario. 


> GRANT SELECT ON test.* TO 'exampleuser'@'192.168.0.%' IDENTIFIED BY 'somepassword';

> show grants for 'exampleuser'@'192.168.0.%';
+----------------------------------------------------------------------------------------------------------------------+
| Grants for exampleuser@192.168.0.% |
+----------------------------------------------------------------------------------------------------------------------+
| GRANT USAGE ON *.* TO 'exampleuser'@'192.168.0.%' IDENTIFIED BY PASSWORD '*DAABDB4081CCE333168409A6DB119E18D8EAA073' |
| GRANT SELECT ON `test`.* TO 'exampleuser'@'192.168.0.%' |
+----------------------------------------------------------------------------------------------------------------------+

Esto permitirá que selecciona sólo para exampleuser del '192 .168.0.%. También debe tener en cuenta que si exampleuser se conecta desde HOST LOCAL que el sistema probablemente localhost usuario en primer lugar antes de la. Dirección de subred 192.168.0% menos que el usuario utiliza la dirección de subred del host conectarse. 

Esto significa que puede crear un usuario y contraseña con privilegios diferentes por host. 


> SHOW GRANTS FOR 'exampleuser'@'localhost';
+--------------------------------------------------------------------------------------------------------------------+
| Grants for exampleuser@localhost |
+--------------------------------------------------------------------------------------------------------------------+
| GRANT USAGE ON *.* TO 'exampleuser'@'localhost' IDENTIFIED BY PASSWORD '*DAABDB4081CCE333168409A6DB119E18D8EAA073' |
| GRANT SELECT, UPDATE, DELETE ON `test`.* TO 'exampleuser'@'localhost' |
+--------------------------------------------------------------------------------------------------------------------+

Haga su mejor esfuerzo para no utilizar la opción - password = opción <contraseña> través del cliente de mysql. Usted puede utilizar-p para que solicite una contraseña. 

Usted también tiene la opción de MySQL 5.6 para utilizar la Utilidad de configuración de MySQL . 


# mysql_config_editor set --login-path=local --host=localhost --user=root --password
Enter password: 




# mysql_config_editor print --all
[local]
user = root
password = *****
host = localhost 


# Mysql
ERROR 1045 (28000): Acceso denegado para el usuario 'root' @ 'localhost' (using password: NO)

# Mysql - login-path = local
Bienvenido al monitor de MySQL.

# Mysql - login-path = local-e "SELECT NOW () ';

Usted tiene opciones para nombrar los diferentes caminos como local o remoto y etc también. Así que usted puede codificar más de una cuenta de usuario de acceso en el archivo ~ /. Mylogin.cnf archivo que se creará una vez que utiliza el comando set. 

Si tiene scripts de shell que utilizan el cliente mysql y es probable entonces que las contraseñas de los scripts de actualización a utilizar el "- login-path =" es una forma más segura de ir. 


Por supuesto, cuando ya no es necesario que un usuario ... Suelta el usuario. 


> DROP USER 'exampleuser'@'localhost';