El tema de los usuarios es relativamente simple, pero a la vez es crítico y algo más complejo que los usuarios de una red, cuando se trata de usuarios de bases de datos.
Tienes que comprender que el sistema de red (Linux) y el servidor de Web (Apache) cuentan con un susbsistema de gestión de usuarios que determina quienes, con qué claves y a qué recursos pueden acceder los diferentes usuarios. Los recursos que pueden usar, componen, en defintiva, los tipos de permisos que se otorgan a los usuarios.
Pero los sistemas de gestión de bases de datos son, por un lado un recurso específico, y por otro son susbsistemas que residen dentro de esos sistemas. Por ello mismo, los Data Base Management System (DBMS) o Sistemas de Gestión de Bases de Datos (SGBD) cuentan a su vez con su propio sistema de gestión de usuarios y permisos.
Esto último implica que los permisos que puedan darse a nivel de Linux son básicamente irrelevantes para el funcionamiento de los DBMS y deben serlo, porque el hecho de que tengas permiso para crear usuarios o ver ciertos ejecutables o documentos dentro de la red,
no necesariamente implica que tengas la autoridad ni el permiso de ver cierta información crítica, como podría serlo el sistema de gestión comercial de una empresa. El hecho que seas el administrador de la red entera, no implica que puedas o debas ver, por ejemplo, la liquidación de sueldos de los empleados, o los pagos a los miembros del directorio, toda información que se encuentra en la base de datos.
¿Se entiende la razón de esa separación?
Habiendo hecho esta introducción, detallo:
- Todos DBMS se instala como cliente o como servidor. El cliente es nada ma´s que una instancia de comunicaciones, y el servidor es quien abastece y responde los datos. por medio de consultas y comandos.
- En todo sistema cliente - servidor hay al menos un usuario administrador que cuenta con todos los privilegios posibles. En el caso de MySQL (heredado de Linux en este caso), se denomina
root. Es el primer usuario creado y posee todos los privilegios al menos en el servidor.
- Todos los usuarios los crea el root, a menos que él mismo le haya otorgado ese privilegio a algún usuario (generalmente denominados superusuarios).
- Cada usuario creado no puede poseer más privilegios de los que el usuario que lo creo poseía, esto es: el usuario B, creado por A no puede hacer más cosas que las que el A tiene permiso, porque como mínimo hereda sus permisos...
- La creación de usuarios consta de dos partes: La creación del nuevo usuario con su password, y el otorgamiento de permisos. El acto de crear un usuario no permite al usuario nuevo hacer nada si no se le dan permisos. De hecho, ni siquiera podría loguearse porque no cuenta con permisos de SESSION (tácito al otorgar cualquier permiso).
- Se puede crear un usuario que acceda a todas las bases de datos o a una sola, o incluso sólo a una tabla, a una tupla o a un procedimiento almacenado. Esto implica que se puede ser muy específico en lo que el usuario puede hacer o no.
EL conjunto completo de permisos posibles (
13.5.1.3. Sintaxis de GRANT y REVOKE) son:
ALL [PRIVILEGES]
Da todos los permisos simples excepto GRANT OPTION
ALTER
Permite el uso de ALTER TABLE
ALTER ROUTINE
Modifica o borra rutinas almacenadas
CREATE
Permite el uso de CREATE TABLE
CREATE ROUTINE
Crea rutinas almacenadas
CREATE TEMPORARY TABLES
Permite el uso de CREATE TEMPORARY TABLE
CREATE USER
Permite el uso de CREATE USER, DROP USER, RENAME USER, y REVOKE ALL PRIVILEGES.
CREATE VIEW
Permite el uso de CREATE VIEW
DELETE
Permite el uso de DELETE
DROP
Permite el uso de DROP TABLE
EXECUTE
Permite al usuario ejecutar rutinas almacenadas
FILE
Permite el uso de SELECT ... INTO OUTFILE y LOAD DATA INFILE
INDEX
Permite el uso de CREATE INDEX y DROP INDEX
INSERT
Permite el uso de INSERT
LOCK TABLES
Permite el uso de LOCK TABLES en tablas para las que tenga el permiso SELECT
PROCESS
Permite el uso de SHOW FULL PROCESSLIST
RELOAD
Permite el uso de FLUSH
REPLICATION CLIENT
Permite al usuario preguntar dónde están los servidores maestro o esclavo
REPLICATION SLAVE
Necesario para los esclavos de replicación (para leer eventos del log binario desde el maestro)
SELECT
Permite el uso de SELECT
SHOW DATABASES
SHOW DATABASES muestra todas las bases de datos
SHOW VIEW
Permite el uso de SHOW CREATE VIEW
SHUTDOWN
Permite el uso de mysqladmin shutdown
SUPER
Permite el uso de comandos CHANGE MASTER, KILL, PURGE MASTER LOGS, y SET GLOBAL , el comando mysqladmin debug le permite conectar (una vez) incluso si se llega a max_connections
UPDATE
Permite el uso de UPDATE
GRANT OPTION
Permite dar permisos
No todos estos permisos se pueden otorgar globalmente con GRANT ALL, como te dije, algunos de ellos se deben otorgar específicamente, y para ello como mínimo
el usuario otorgante debe tener ese permiso para si mismo.
Entre ellos, están: FILE, PROCESS, RELOAD, REPLICATION CLIENT, REPLICATION SLAVE, SHOW DATABASES, SHUTDOWN, y SUPER.
¿Se va entendiendo la problemática de los permisos?
En tu caso lo que hay que comprobar es cuál es el nivel de permisos que el user utilizado tiene, porque, como ya dije,
puede darse el caso de no contar con el permiso de FILE, con lo que cualquier operación LOAD DATA contra el servidor será inútil, ya que no tienes permiso para hacerlo.
Lo más simple es ejecutar
Eso te mostrará el nivel real de privilegios del usuario en curso.
Ten en cuenta que incluso si usas el
root, si estás en modo
remoto,
es posible que el root no tenga permiso de FILE para hacer tareas en remoto. Esto es porque
los permisos remotos y los permisos en localhost se otorgan por separado.
De hecho, si le das al mismo usuario varios niveles de permisos según el host desde donde se conecte, puedes encontrar que el la tabla de usuarios ese username aparece varias veces, una por cada host autorizado.