Is it possible to set role with access to one database, with all privileges except to drop tables?
Not really. If a user can issue CREATE TABLE, it can issue a DROP for that table as well. From the docs:
The right to drop an object, or to alter its definition in any way, is not treated as a grantable privilege; it is inherent in the owner, and cannot be granted or revoked.
And as noted by the CREATE TABLE docs:
The table will be owned by the user issuing the command.
There is no mechanism to allow a user to create tables that they do not own and therefore cannot drop.
Related
I'm trying to allow a database user to be able to alter/drop (certain) tables, but not GRANT privileges on them. Is this possible?
It looks like they need to be the owner of the tables, but from https://www.postgresql.org/docs/current/sql-grant.html
The right to drop an object, or to alter its definition in any way, is not treated as a grantable privilege; it is inherent in the owner, and cannot be granted or revoked. (However, a similar effect can be obtained by granting or revoking membership in the role that owns the object; see below.) The owner implicitly has all grant options for the object, too.
This sounds like it's not possible. However, is this definitely the case? Is there some way with triggers for example to make certain GRANTs fail?
Yes, only the owner of a table or a superuser can ALTER or DROP it, and these users can always GRANT privileges on the table.
Your only option is to create an event trigger that fires on GRANT and throws an error for the tables where it should be forbidden.
I have a database shared by many users, all the users are in a group "example" and the vast majority of objects in the database are owned by "example". Very occasionally a user will create a new table - that table gets assigned to the user who created it and so the other users are unable to alter the new table.
Is there a way to have the ownership of a table automatically set to the group "example" and not the user who created the table or a way to set up a trigger that happens after a CREATE TABALE or a way to set up group/permissions such that all users will be considered owners of objects regardless of who actually created them?
You could change the default privileges this way:
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO PUBLIC;
or to give write access:
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT,INSERT,UPDATE,DELETE ON TABLES TO PUBLIC;
https://www.postgresql.org/docs/9.0/static/sql-alterdefaultprivileges.html
You probably want to use an EVENT TRIGGER
This is doable in all versions of Pg from 9.3 forward but depending on your version might require different approaches since the structures for event triggers have improved significantly.
In earlier versions you could look through the table catalogs for items owned by the current user. In newer versions you can use pg_event_trigger_ddl_commands to get the information you need. you want to run the command at ddl end.
created two schemas in redshift and one has all tables and other schema has views created from earlier schema tables. Users were granted select privileges on second schema views. When trying to query one particular view using select in redshift, it throws "Job::UserError: PG::InsufficientPrivilege: ERROR: permission denied for schema".
The error comes only when accessing that particular view, all others are absolutely fine.
Verified the privileges and users do have select permission on views and tables. Any direction would be helpful.
You must also grant the USAGE privilege on the new schema:
GRANT USAGE ON SCHEMA <schema_name> TO <schema_user>
If you find that this is only affecting one particular view, it may be because the view was dropped and recreated after the privileges were assigned (and therefore the table has lost its inheritance of the schema permissions).
The solution may be to:
Reapply the privileges
Next time you need to change the view, rather than DROP and then CREATE the view, use the CREATE OR REPLACE VIEW your_view_name AS command
We're using PostgreSQL 9.4.
We need to prevent users from doing an ALTER on a table, not even the owner of the table.
The owner of the table would have to 'grant' himself the permission to do the ALTER.
I imagine it would be like setting a 'read only flag' on the table's schema.
The table in question is being inherited from another table, if this has any importance.
The ideal solution would allow to do a message like "You can't ALTER the table because .... "
Is this achievable? and if so, how?
This is probably not what you actually want, but a potentially interesting effect:
When creating an inherited table, you have to do it as the owner of the parent table, but you can then change the owner of the child table. The new owner won't be able to drop/modify the inherited set of columns, though will still be able to change defaults/checks/triggers/etc, and to add new columns.
The simplest way to do something close to what you actually want is probably to control access by the owner role: create a separate role to access the tables, and revoke the CONNECT privilege on the database from the owner.
When I try to alter a table from a different owner in Firebird I got this error:
unsuccessful metadata update
MODIFY RDB$RELATION_FIELDS failed
no permission for control access to TABLE TAGS
I had already granted ALL privileges to this user, also REFERENCES privileges, but I still getting this error.
Does anybody knows how to solve this?
I use Firebird 1.5
Thanks
The Firebird 2.5 Language Reference section on ALTER TABLE states:
Only the table owner and administrators have the authority to use
ALTER TABLE.
In other words if you are not the owner of the table, you need to either login as SYSDBA, or you need to be logged in as root or Adminstrator on the machine with the database. There is - as far as I am aware - no other way to alter a table as a different user.
In Firebird 2.5 there is also the RDB$ADMIN role which allows a user which is granted this role to act with the same rights as SYSDBA.
The rights you can GRANT (except for REFERENCES) are only for DML, not for DDL operations.
Firebird 3 introduced metadata privileges, which allows you to grant these permissions to a specific user or role for specific object types.
For example:
GRANT ALTER ANY TABLE TO Joe;
Will allow the user Joe to alter any tables in the current database.