Roles y Permisos en Vivo

Si todavía no viste la teoría, repasa primero Seguridad: Roles, GRANT y REVOKE antes de continuar. Este taller usa una única tabla, productos, y una segunda tabla, log_accesos, que vas a crear en el reto final.

Esta página corre su propia base de datos, independiente de cualquier otro taller que hayas abierto antes. Existe solo mientras esta pestaña siga abierta: si recargas la página, la cierras, o navegas a otra guía, se pierde todo y hay que empezar de nuevo desde "Prepara tu base de datos". Si te equivocás y querés reiniciar sin recargar, usa el botón "Reiniciar base de datos" de abajo.

Si en algún momento un bloque te da errores raros de permiso que no esperabas, probablemente quedaste con un SET ROLE activo de un ejercicio anterior. Ejecutá RESET ROLE; acá mismo para volver a tu identidad original antes de seguir.

El SELECT final debería mostrarte 5 filas, en el mismo orden de la tabla de arriba. Si algo no coincide, usa "🔄 Reiniciar base de datos" y volvé a intentar — el resto del taller asume exactamente estos precios y este stock.

Crea un rol llamado lector, sin ninguna cláusula extra — todavía no puede conectarse a nada, ni tiene ningún permiso.

Crea un segundo rol llamado editor, esta vez con WITH LOGIN PASSWORD '...' (cualquier contraseña que elijas).

Confirma la diferencia entre ambos: SELECT rolname, rolcanlogin FROM pg_roles WHERE rolname IN ('lector', 'editor');

editor debería mostrar rolcanlogin = true; lector, false.

Cambiá tu identidad a lector y probá leer productos: SET ROLE lector; seguido de SELECT * FROM productos; — debería fallar. Al final, volvé a tu identidad original con RESET ROLE;.

Deberías ver permission denied for table productos. No es un bug — es exactamente lo que tiene que pasar: lector todavía no tiene ningún permiso sobre esa tabla.

Otorgá el permiso de lectura: GRANT SELECT ON productos TO lector; Después repetí el mismo SET ROLE + SELECT del ejercicio anterior, y confirmá que ahora sí funciona. Terminá con RESET ROLE;

El mismo SELECT que falló en 2.1 ahora te devuelve las 5 filas de productos. Lo único que cambió fue el GRANT.

Todavía como lector, intentá insertar una fila nueva — debería fallar, porque solo le diste SELECT: SET ROLE lector; INSERT INTO productos (nombre, precio, stock) VALUES ('Ropero', 200, 2); RESET ROLE;

Otra vez permission denied for table productos — pero esta vez es un error distinto en el fondo: lector sí puede leer, pero INSERT es un privilegio aparte que nunca se le otorgó.

Otorgá GRANT INSERT ON productos TO editor;. Después, como editor, intentá INSERT INTO productos (nombre, precio, stock) VALUES ('Ropero', 200, 2); — debería fallar igual, con un mensaje distinto al de 2.3. Terminá con RESET ROLE;

Esta vez el error es permission denied for sequence productos_id_seq — no "for table". La columna id es SERIAL, y por dentro eso usa una secuencia aparte para generar cada número. INSERT sobre la tabla no alcanza: hace falta USAGE sobre esa secuencia también.

Otorgá GRANT USAGE, SELECT ON SEQUENCE productos_id_seq TO editor;. Repetí el mismo INSERT de 3.1 como editor — ahora sí debería funcionar. Terminá con RESET ROLE;

Confirmá con SELECT COUNT(*) FROM productos; en la zona de pruebas libres — debería mostrarte 6 (las 5 originales más "Ropero").

Retirale a lector el permiso de lectura que le diste en 2.2: REVOKE SELECT ON productos FROM lector; Después, como lector, repetí el mismo SELECT * FROM productos; de siempre — debería volver a fallar. Terminá con RESET ROLE;

El mismo error de 2.1, permission denied for table productos — REVOKE deshizo exactamente lo que había hecho GRANT en 2.2, sin tocar los permisos de editor.

Otorgale a editor también SELECT y UPDATE: GRANT SELECT, UPDATE ON productos TO editor; Creá un rol nuevo, admins, y hacelo miembro de editor: CREATE ROLE admins; GRANT editor TO admins;

Como admins, probá leer y modificar productos —sin haberle otorgado ningún permiso a admins directamente—: SET ROLE admins; SELECT nombre FROM productos ORDER BY id; UPDATE productos SET precio = 45 WHERE nombre = 'Silla'; RESET ROLE;

admins nunca recibió un GRANT directo sobre productos — pero como es miembro de editor, hereda automáticamente todo lo que editor tenga en cualquier momento. Confirmá el nuevo precio de Silla con SELECT nombre, precio FROM productos WHERE nombre = 'Silla'; en la zona de pruebas libres.

• 1. Crea una tabla nueva, log_accesos, con columnas id (clave primaria autoincremental), rol (texto) y fecha (con DEFAULT now()).
• 2. Crea un rol nuevo, auditor, y otorgale SELECT, INSERT ON log_accesos — más el USAGE sobre su secuencia (repasá la sección 3 si no te acordás el nombre exacto: nombretabla_id_seq).
• 3. Como auditor, insertá una fila en log_accesos con rol = 'auditor', y confirmá que SELECT * FROM log_accesos; funciona.
• 4. Todavía como auditor, intentá SELECT * FROM productos; — debería fallar, aunque auditor ya tenga permisos sobre otra tabla.

Que un rol tenga acceso a log_accesos no le da ningún acceso a productos —cada GRANT es específico de un objeto y un rol, nunca general. Esto es justamente lo que hace que el principio de mínimo privilegio sea posible: podés darle a auditor exactamente lo que necesita (su propia tabla de registro) sin abrirle ni una fila de las demás tablas de la base.