Utilizando PostgreSQL 9.0, tengo un rol de grupo llamado "personal" y me gustaría otorgar todos (o ciertos) privilegios a este rol en tablas en un esquema particular. Ninguno de los siguientes trabajos

GRANT ALL ON SCHEMA foo TO staff;
GRANT ALL ON DATABASE mydb TO staff;

Los miembros del "staff" todavía no pueden SELECCIONAR o ACTUALIZAR en las tablas individuales en el esquema "foo" o (en el caso del segundo comando) en cualquier tabla en la base de datos a menos que otorgue todo en esa tabla específica.

¿Qué puedo hacer para facilitar mi vida y la de mis usuarios?

Actualización: lo resolví con la ayuda de una pregunta similar en serverfault.com .

GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA foo TO staff;

Encontraste la abreviatura para establecer privilegios para todas las tablas existentes en el esquema dado. El manual aclara :

(pero tenga en cuenta que ALL TABLESse considera que incluye vistas y tablas externas ).

El énfasis audaz es mío. seriallas columnas se implementan con nextval()una secuencia como columna predeterminada y, citando el manual :

Para secuencias, este privilegio permite el uso de las funciones currvaly nextval.

Entonces, si hay serialcolumnas, también querrá otorgar USAGE(o ALL PRIVILEGES) en secuencias

GRANT USAGE ON ALL SEQUENCES IN SCHEMA foo TO mygrp;

Nota: las columnas de identidad en Postgres 10 o posterior usan secuencias implícitas que no requieren privilegios adicionales. (Considere actualizar las serialcolumnas).

¿Qué pasa con los objetos nuevos ?

También le interesarán los DEFAULT PRIVILEGESusuarios o esquemas :

ALTER DEFAULT PRIVILEGES IN SCHEMA foo GRANT ALL PRIVILEGES ON TABLES TO staff;
ALTER DEFAULT PRIVILEGES IN SCHEMA foo GRANT USAGE          ON SEQUENCES TO staff;
ALTER DEFAULT PRIVILEGES IN SCHEMA foo REVOKE ...;

Esto establece privilegios para los objetos creados en el futuro automáticamente, pero no para los objetos preexistentes.

Los privilegios predeterminados solo se aplican a los objetos creados por el usuario objetivo ( FOR ROLE my_creating_role). Si se omite esa cláusula, el valor predeterminado es la ejecución del usuario actual ALTER DEFAULT PRIVILEGES. Para ser explícito:

ALTER DEFAULT PRIVILEGES FOR ROLE my_creating_role IN SCHEMA foo GRANT ...;
ALTER DEFAULT PRIVILEGES FOR ROLE my_creating_role IN SCHEMA foo REVOKE ...;

Tenga en cuenta también que todas las versiones de pgAdmin III tienen un error sutil y muestran privilegios predeterminados en el panel SQL, incluso si no se aplican a la función actual. Asegúrese de ajustar la FOR ROLEcláusula manualmente al copiar el script SQL.

Mi respuesta es similar a esta en ServerFault.com .

Ser conservador

Si desea ser más conservador que otorgar "todos los privilegios", es posible que desee probar algo más parecido a estos.

GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO some_user_;
GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA public TO some_user_;

El uso de publicallí se refiere al nombre del esquema predeterminado creado para cada nueva base de datos / catálogo. Reemplácelo con su propio nombre si creó un esquema.

Acceso al esquema

Para acceder a un esquema, para cualquier acción, el usuario debe tener derechos de "uso". Antes de que un usuario pueda seleccionar, insertar, actualizar o eliminar, primero se le debe otorgar "uso" a un esquema.

No notará este requisito cuando utilice Postgres por primera vez. De forma predeterminada, cada base de datos tiene un primer esquema denominado public. Y a cada usuario de forma predeterminada se le han otorgado automáticamente derechos de "uso" para ese esquema en particular. Al agregar un esquema adicional, debe otorgar derechos de uso explícitamente.

GRANT USAGE ON SCHEMA some_schema_ TO some_user_ ;

Extracto del documento de Postgres :

Para los esquemas, permite el acceso a los objetos contenidos en el esquema especificado (suponiendo que también se cumplan los requisitos de privilegios propios de los objetos). Esencialmente, esto permite al beneficiario "buscar" objetos dentro del esquema. Sin este permiso, todavía es posible ver los nombres de los objetos, por ejemplo, consultando las tablas del sistema. Además, después de revocar este permiso, los backends existentes pueden tener declaraciones que hayan realizado esta búsqueda anteriormente, por lo que esta no es una forma completamente segura de evitar el acceso a objetos.

Para obtener más información, consulte la pregunta: ¿Qué hace exactamente el USO DE SUBVENCIONES EN EL ESQUEMA? . Preste especial atención a la respuesta del experto de Postgres Craig Ringer .

Objetos existentes versus futuro

Estos comandos solo afectan a los objetos existentes. Las tablas y demás que cree en el futuro obtienen privilegios predeterminados hasta que vuelva a ejecutar las líneas anteriores. Vea la otra respuesta de Erwin Brandstetter para cambiar los valores predeterminados que afectan a los objetos futuros.