Esta página describe Calíope 1.7, la versión que estoy construyendo ahora mismo. La 1.6 está en la App Store para Mac, iPad, iPhone, Apple Watch, Apple TV y Apple Vision Pro. El changelog dice en qué versión llegó cada función.
Añade un botón «Abrir en Calíope» a cada tema. Sólo funciona con la app instalada.
Crea, edita y elimina cuentas del servidor con sus privilegios.
Dónde está: Espacio de Trabajo › Herramientas › Usuarios
Abre Usuarios desde la barra de navegación del workspace. El panel de la izquierda lista todas las cuentas del servidor, con las del sistema agrupadas aparte; el buscador filtra por nombre. Selecciona una cuenta para cargar sus privilegios.
Lo que aparece a la derecha depende del motor, porque el modelo de seguridad no es el mismo. En MySQL y MariaDB una cuenta es usuario@host y los privilegios se conceden en cuatro ámbitos: Global, Base de datos, Tabla y Rutina. En PostgreSQL una cuenta es un rol, no hay host, y en lugar del ámbito global aparecen sus atributos, que no se conceden sino que se ponen. Lo que un motor no tiene no se dibuja apagado: no se dibuja.
Dentro de cada tarjeta las casillas van agrupadas por Datos, Estructura, Rutinas, Administración y Replicación. Marca lo que corresponda y pulsa Guardar cambios; mientras haya cambios sin aplicar la cabecera lo indica, y Descartar cambios vuelve a lo que hay en el servidor.
En SQL Server una cuenta es un inicio de sesión del servidor, sin host; en cada base actúa a través del usuario enlazado a él, que Calíope encuentra solo. Los privilegios van en cinco ámbitos —Global (el servidor), Conexión (una base), Base de datos (un esquema), Tabla y Rutina— y un DENY se enseña como un tercer estado, tachado y con su nombre: aquí se ve pero no se cambia; se pone y se quita desde el Editor SQL.
Sin permiso para leer las cuentas —en MySQL y MariaDB, SELECT sobre la base mysql— la lista dice «No se pudieron leer las cuentas del servidor», con el motivo del servidor debajo y un botón para reintentar, y el pie no enseña cifra. En PostgreSQL no ocurre: cualquier cuenta puede leer los roles. En SQL Server, sin VIEW ANY DEFINITION se ven menos cuentas, sin error. Y en Respaldos, sin ese permiso la sección de cuentas del servidor no aparece.
ClickHouse
En ClickHouse la lista trae las cuentas y los roles juntos. Las cuentas definidas en el archivo de configuración del servidor, y default, salen en Sistema con un candado: no se pueden cambiar por SQL. Una revocación parcial —conceder sobre una base y revocar sobre una de sus tablas— sale en la tarjeta de esa tabla tachada y con la palabra REVOKE: aquí se ve pero no se cambia. Los privilegios de cada tarjeta los da el servidor, así que cambian con su versión. El permiso para escribir es de la conexión: si tu cuenta no tiene ACCESS MANAGEMENT o CREATE USER, también a través de un rol, la herramienta lista igual, pero los botones salen apagados y una franja con un candado dice por qué. Los cambios son inmediatos, no hay límites por hora y para conceder sólo se ofrecen roles.
Oracle
En Oracle la lista trae las cuentas y los roles juntos, más PUBLIC, el rol al que pertenece todo el mundo; las cuentas y los roles del propio Oracle salen en Sistema. Cada cuenta es dueña del esquema que lleva su nombre. Los privilegios van en cuatro ámbitos: Global (los de sistema, como CREATE TABLE), Base de datos (los de un esquema entero, como SELECT ANY TABLE sobre él), Tabla y Rutina, donde también salen los paquetes. Encima van el perfil con sus límites de contraseña, cuándo caduca la contraseña y el tablespace: se leen, no se cambian aquí. De PUBLIC y de las cuentas de Oracle sólo se enseña lo concedido sobre esquemas de usuario. Sin permiso para leer DBA_USERS la lista trae sólo tu cuenta, con sus roles y sus permisos, y una franja lo dice. Los permisos sobre secuencias, tipos y columnas no se enseñan. Escribir pide a tu conexión un privilegio de sistema por acción: CREATE USER para crear, ALTER USER para cambiar la contraseña o bloquear, DROP USER para eliminar, y GRANT ANY PRIVILEGE, GRANT ANY OBJECT PRIVILEGE o GRANT ANY ROLE para conceder; sin él, ese botón sale apagado y dice cuál falta. Las cuentas de Oracle no se cambian desde aquí: una franja lo dice.
Con una etiqueta de entorno de solo lectura, esta herramienta no se ofrece. Con una que confirma lo que escribe, cada cambio —crear o editar un usuario, sus privilegios, sus roles— pregunta antes con el nombre de la acción, y borrar un usuario lleva la etiqueta en el título de su confirmación.
Palabras clave: usuarios, roles, privilegios, permisos, GRANT, user admin
Pulsa Nuevo usuario en la barra de Usuarios. Introduce el nombre, el host y la contraseña. La cuenta se crea sin privilegios y queda seleccionada, para asignárselos a continuación.
El campo host y el selector de método de autenticación sólo aparecen donde el motor los tiene. En PostgreSQL no hay ninguno de los dos: desde dónde se admite una conexión lo decide el archivo pg_hba.conf del servidor, y el método de cifrado de la contraseña lo decide la configuración del servidor, no la cuenta. El rol se crea con LOGIN e INHERIT, como hace CREATE USER, así que puede entrar; sus demás atributos se marcan después en su propia tarjeta.
SQL Server tampoco: la cuenta es un inicio de sesión, sin host y sin método que elegir.
Oracle
En Oracle no hay host ni método: la cuenta se crea con CREATE USER … IDENTIFIED BY y recibe CREATE SESSION, que es lo que la deja entrar. La contraseña no puede llevar comillas dobles. Sin contraseña se crea una cuenta de sólo esquema (NO AUTHENTICATION), que guarda objetos pero no puede entrar. El tablespace y la cuota los pone el servidor: sin cuota la cuenta no guarda filas, y se le da desde el Editor SQL (ALTER USER … QUOTA). En una base enchufable (PDB) un nombre que empieza por C## es de usuario común y no se crea aquí: el formulario lo dice.
Palabras clave: crear usuario, nuevo usuario, CREATE USER, contraseña
Selecciona la cuenta en el panel de la izquierda y pulsa Eliminar en la cabecera. Un diálogo de confirmación muestra qué se va a eliminar. La acción es irreversible.
Las cuentas que instala el servidor aparecen en su propio grupo y no se pueden eliminar desde aquí.
En PostgreSQL el servidor puede negarse, y no es un fallo de Calíope: un rol que posee objetos o que tiene privilegios concedidos no se puede borrar hasta que se le quiten. Calíope no emite DROP OWNED BY por su cuenta, porque eso borraría datos que nadie ha pedido borrar. Quita antes sus concesiones —incluidas las de «todas las tablas», que dejan además un privilegio por omisión— o traspasa lo que posee.
En SQL Server borrar quita el usuario de la cuenta en cada base y después el inicio de sesión. El servidor se niega mientras uno de esos usuarios sea dueño de un esquema: pasa antes el esquema a otro (ALTER AUTHORIZATION).
Oracle
En Oracle una cuenta es su esquema: eliminarla es DROP USER … CASCADE, que borra también todas sus tablas, vistas y código, y la confirmación lo dice. Un rol se elimina con DROP ROLE. Las cuentas de Oracle no se eliminan desde aquí.
Palabras clave: eliminar usuario, DROP USER, borrar, revocar
Selecciona la cuenta en el panel de la izquierda y pulsa Editar en la cabecera. Se abre el formulario de edición.
El formulario enseña sólo lo que el motor tiene. En MySQL y MariaDB lleva la contraseña, el método de autenticación, el bloqueo de la cuenta y los límites de recursos por hora. En PostgreSQL lleva la contraseña y nada más: no hay bloqueo —una cuenta se cierra quitándole el atributo LOGIN, que se ve en su tarjeta— ni límites por hora, y el número de conexiones simultáneas y la caducidad se editan junto a los atributos.
El formulario se abre con lo que tiene el servidor: si la cuenta está bloqueada y sus límites por hora. Un límite de 0 es sin límite, y volver a ponerlo a 0 lo quita. Deja el campo de contraseña vacío si sólo quieres cambiar el resto de ajustes.
En SQL Server lleva la contraseña y el bloqueo (ALTER LOGIN … DISABLE: el inicio de sesión no puede entrar y conserva sus permisos); no hay límites por hora ni fecha de caducidad por cuenta.
Oracle
En Oracle lleva la contraseña y el bloqueo (ALTER USER … ACCOUNT LOCK: la cuenta no puede entrar y el servidor contesta ORA-28000). No hay límites por hora: los de la contraseña los pone su perfil, que se ve en la cabecera de la cuenta. La contraseña no puede llevar comillas dobles.
Palabras clave: cambiar contraseña, password, editar usuario, ALTER USER, credenciales, nueva contraseña
Gestionar privilegios por base de datos, tabla y rutina
Asigna permisos granulares a nivel de BD, tabla o rutina específica.
Dónde está: Usuarios › Árbol de privilegios
Cada ámbito de privilegios es una tarjeta con su contador de concedidos y su interruptor WITH GRANT OPTION:
- Atributos del rol — sólo PostgreSQL. No son privilegios: son propiedades del rol (LOGIN, SUPERUSER, CREATEDB…) y se escriben con ALTER ROLE. Al pie van las conexiones simultáneas y la caducidad.
- Global — familia MySQL y SQL Server. Aplican a todo el servidor (p. ej. SUPER o PROCESS en MySQL, VIEW SERVER STATE en SQL Server).
- Conexión — PostgreSQL y SQL Server. En PostgreSQL, los privilegios de la base del clúster a la que apunta el perfil: CONNECT, CREATE y TEMPORARY, que deciden si la cuenta puede siquiera conectarse. En SQL Server, los de una base entera (CONNECT, CREATE TABLE…).
- Base de datos — sobre todos los objetos de una base (en PostgreSQL y SQL Server, de un esquema).
- Tabla — sobre una tabla concreta.
- Rutina — sobre un procedimiento o función almacenados.
Dentro de cada tarjeta las casillas van agrupadas por categoría, con Marcar todo por grupo, y ALL PRIVILEGES está destacado arriba porque concede el ámbito entero de una vez.
Para añadir un ámbito que no aparece, usa Agregar objeto en la barra inferior. Guardar cambios ejecuta los REVOKE y GRANT necesarios; si el servidor rechaza alguno, aparece un aviso junto al botón con el detalle. En MySQL y MariaDB ejecuta después FLUSH PRIVILEGES, igual que crear, editar y eliminar una cuenta.
ClickHouse
Con ClickHouse hay tres tarjetas: Global, Base de datos y Tabla. No hay Rutina, Conexión ni atributos del rol.
Oracle
Con Oracle hay cuatro tarjetas: Global (los privilegios de sistema; su interruptor es la ADMIN OPTION), Base de datos (los privilegios sobre un esquema entero, como SELECT ANY TABLE ON SCHEMA), Tabla (también vistas y vistas materializadas) y Rutina (procedimientos, funciones y paquetes). No hay Conexión ni atributos del rol.
Palabras clave: privilegios, GRANT, REVOKE, base de datos, tabla, rutina, permisos granulares, columnas, EXECUTE, SUPER
Por qué esta pantalla no se parece a la de MySQL, y qué significa cada parte.
Dónde está: Espacio de Trabajo › Herramientas › Usuarios
En PostgreSQL no hay usuarios y grupos por separado: hay roles, y un rol es las dos cosas a la vez. Un rol con el atributo LOGIN sirve para entrar; uno sin él sirve para agrupar privilegios y dárselos a otros. Por eso la pantalla cambia de forma, y no por capricho.
No hay host. Una cuenta es un nombre a secas. Desde dónde se admite una conexión lo decide pg_hba.conf, que es del servidor y no de la cuenta, así que Calíope no lo enseña aquí ni lo puede cambiar.
Los atributos no son privilegios.SUPERUSER, CREATEDB, CREATEROLE, REPLICATION, BYPASSRLS, INHERIT y LOGIN se ponen con ALTER ROLE, no se conceden con GRANT. Al guardar, Calíope escribe todos: lo que dejes sin marcar queda apagado. Es lo que hace que la pantalla diga la verdad — si sólo se escribiera lo marcado, desmarcar una casilla no la apagaría y volvería sola la próxima vez que abrieras la cuenta.
La pertenencia es transitiva. Si app pertenece a lectores y lectores a auditores, entonces app tiene lo de auditores sin que nadie se lo haya concedido. La tarjeta Pertenece a distingue las pertenencias directas de las heredadas y enseña el camino de cada una. Las heredadas no se pueden quitar desde aquí, y por eso no llevan botón: lo que habría que revocar es el eslabón, y ése es de otro rol.
PUBLIC no es un rol: es todo el mundo. Aparece en la lista como una cuenta más porque, si no, un objeto concedido a todos se vería como privado. Por omisión PUBLIC puede conectarse a la base y ejecutar cualquier función.
El propietario tiene todo sobre lo suyo, y eso no aparece como concesión. Una tabla recién creada no tiene ninguna fila de privilegios en el catálogo, y aun así su dueño puede hacer con ella lo que quiera. Por eso la cabecera lleva la ficha «propietario de N objetos» y esas tarjetas se dibujan marcadas y en gris: no hay nada que conceder ni que revocar.
«Conceder a todas las tablas» son dos sentencias. En MySQL, ON base.* cubre también las tablas que se creen mañana; aquí hacen falta dos órdenes que no significan lo mismo: una alcanza a las tablas que existen ahora y otra a las futuras. La segunda, además, sólo cubre las que cree la cuenta con la que Calíope está conectada. Ninguna de las dos vuelve luego como una casilla de la tarjeta del esquema, porque no son privilegios del esquema. El botón de al lado las deshace las dos, y hace falta: mientras quede el privilegio por omisión, el servidor no deja borrar la cuenta.
Lo que no está. No hay bloqueo de cuenta —se quita LOGIN—, no hay límites por hora —sólo el número de conexiones simultáneas—, no hay selector de método de autenticación —lo decide el servidor— y no hay FLUSH PRIVILEGES: aquí el catálogo es la fuente, y un GRANT ya está en vigor cuando el servidor contesta.