I am running a stored procedure in DB2 10.1 which creates a created global temporary table and it returns the following error message that seems to say that it cannot select from the temporary table that it has just created in the same stored procedure
"USER" does not have the required authorization or privilege to
perform operation "SELECT" on object "MYSCHEMA.MYTABLE"..
SQLCODE=-551, SQLSTATE=42501, DRIVER=4.16.53
I have not encountered this problem with the other stored procedures and they create temp tables in the same way. The user privileges are controlled by groups, but due to issues with the groups I have started to give privileges to the users directly.
I cannot grant select permissions to the temp table because its not yet created and not sure how to fix this situation.
Has anyone come across this problem before and if so how did you fix it?
Thanks for any help.
Related
How to create user that can create only tables in database?
grant create on database sport to test1; is wrong because we can create triggers too
There is no way to do that except with an event trigger that throws an error whenever the wrong user creates certain objects.
Note that creating tables or triggers is not connected to permissions on the database, but to permissions on the schema. It seems strange and arbitrary to me to prevent a user that can create tables from adding triggers to these tables.
I'm trying to truncate a table in redshift but it's throwing the following error -
SQL Error [500310] [42501]: Amazon Invalid operation: must
be owner of relation table;
I have already granted all the privileges on the table to the user. As checked through the online documentation for redshift, I can't grant the truncate table access explicitly like the way it's enabled now in PostgreSQL. Is there a way or a best practice to handle this scenario?
As you say only the table owner or a superuser can truncate a table. There are several options.
Change the table to be owned by the user that needs to truncate but this may not meet other constraints
Alter table to current user, truncate, and alter it back to the previous user (requires DROP permission)
Drop and recreate the table but this may break dependencies
Make a table LIKE the original, perform an ALTER TABLE APPEND to this new table, and then drop the new table (some restrictions like no identity columns)
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
Is it possible to grant privileges to allow developers to Create/Declare Temp table/variables but not allow Create Table.
Developers are asked to analyse data from different data sources and a temp table would help a lot.
Because of how the feature is supposed to be used, no special authorization is required:
Authorization
None are required, unless the LIKE clause is specified when additional
privileges might be required.
PUBLIC implicitly has the following privileges without GRANT authority
for declared temporary tables:
The CREATETAB privilege to define a declared temporary table in the database that is defined AS WORKFILE, which is the database for declared temporary tables.
The USE privilege to use the table spaces in the database that is defined as WORKFILE.
All table privileges on the table and authority to drop the table. (Table privileges for a declared temporary table cannot be granted or revoked.)
These implicit privileges are not recorded in the DB2® catalog and
cannot be revoked.
The exceptions for the LIKE clause basically amount to needing SELECT access to the table/columns, which you'd need anyways...
Since temporary tables require a special type of tablespace, user temporary, I think you should be able to accomplish this indirectly: issue GRANT USE OF TABLESPACE on the user temporary tablespace(s) while revoking that privilege on all regular tablespaces.