I need to grant permission to the master user(MasterUsername) the access of of pg_catalog.
GRANT USAGE ON SCHEMA pg_catalog TO <master-user>;
On running this, I get the below warning:
WARNING: no privileges were granted for "pg_catalog".
Essentially, I have an automation script, where I create the database, I set search path and :
SET search_path = <my-schema>, pg_catalog;
CREATE TYPE <type> AS (
id bigint,
name character varying);
I get below error
Caused by: org.postgresql.util.PSQLException: ERROR: permission denied for schema pg_catalog
Essentially, it's not allowing me to create type, since the pg_type table exists in pg_catalog. How to create type?
I don't know if granting the USAGE rights will help? If there's another way to work-around this, please do let me know.
granting usage rights will only let you be able to access objects of a schema, creating new objects will require create privileges on that schema.
The way I worked around this is very simple, I created a role postgres using CREATE ROLE postgres, I assigned it to my user.
Added to search path public and the database by SET search_path=public,<database>
Assigning this to my user actually gave me all the rights I needed to create custom pg_type, use the schema pg_catalog in public schema. How this worked? I don't know, may be postgres guys can answer this? Or the AWS RDS guys can answer this may be.
Secondly, I faced another issue in using the pg_functions and the functions of extension Postgis, even they were resolved by adding the role postgres role to the user who needed to access the function.
I still think this is a workaround and not a direct fix, or may be a fix but there should be some documentation around this(which I did not find).
Related
I am having issues with dropping a user becauase it has default privileges, but I am as well unable to revoke those privileges.
To reproduce my issue:
-- executed with master user redshift_master
CREATE USER anton_test_user PASSWORD '***' IN GROUP redshift_dev;
Then using anton_test_user
CREATE SCHEMA anton_test_schema;
CREATE TABLE anton_test_schema.anton_test_table AS SELECT 1 AS anton;
ALTER DEFAULT PRIVILEGES IN SCHEMA anton_test_schema
GRANT SELECT ON TABLES TO GROUP redshift_readonly;
Again with redshift_master
ALTER SCHEMA anton_test_schema OWNER TO redshift_master;
ALTER TABLE anton_test_schema.anton_test_table OWNER TO redshift_master;
Now trying to drop the user it complains about default privileges:
DROP USER anton_test_user;
Result as expected:
owner of default privileges on new relations belonging to user
anton_test_user in schema anton_test_schema;
Now to the weird part, still with redshift_master
ALTER DEFAULT PRIVILEGES FOR USER anton_test_user IN SCHEMA anton_test_schema
REVOKE ALL ON TABLES FROM redshift_readonly;
Gives Invalid operation: permission denied for schema anton_test_schema. What?
If running with anton_test_user
ALTER DEFAULT PRIVILEGES IN SCHEMA anton_test_schema
REVOKE ALL ON TABLES FROM redshift_readonly;
As well gives Invalid operation: permission denied for schema anton_test_schema.
The only way for me to solve this and being able to drop anton_test_user was to, with redshift_master drop the schema and table completely
DROP TABLE anton_test_schema.anton_test_table;
DROP SCHEMA anton_test_schema;
DROP USER anton_test_user; -- it works now
Transfering ownership back to anton_test_user and then revoking default privileges did not help - dropping the table and schema was the only solution I could find.
My completely uninformed guess is that anton_test_user had lost permissions to the schema, so no grants for the user could be applied or revoked in that schema.
Question(s):
Is there any way to avoid dropping anton_test_schema and anton_test_table while also dropping anton_test_user?
Is it supposed to work this way?
Do Postgres behave in the same way?
This is a bit of a follow up to a question already asked, to which I gave an answer - but I have no idea what is going on even though I came up with a "solution" ("" because dropping objects was a solution, albeit a pretty poor one). It might be that I have completely misunderstood user privileges in Redshift as well.
The original question is not completely the same as this - and I would like to know what is going on, so it is not really a repost even though it might look like it.
I had the same issue myself. I was able to avoid dropping the user/schema by first re-granting access of the schema to my end user (my version of anton_test_user).
grant all on schema analyst_data to anton_test_user;
After doing so, I was able to run my alter default privileges command
ALTER DEFAULT PRIVILEGES for user <user> in schema <schema> REVOKE ALL on tables FROM group <group>;
Your uninformed guess was spot on 😀
I'm extremely new to PostgreSQL and I just installed it using Homebrew.
I ran through creating and connecting to a database and now I'm trying to create a table with the standard command CREATE TABLE users(name string, age smallint, birthday date) and the command completes. However as soon as I run the command to list all tables I get the following Did not find any relations.
I checked all users and privileges and it looks like my profiles roles include Superuser, Create Role, Create DB, Replication, Bypass RLS and I'm a member of {}.
I'm not sure if there's something more I need to do in order to create tables under a certain database or not, but I've looked all over and can't seem to find an answer to this.
I'm not really sure what you're intending to do, be more explicit.
But it seems to me you've juste created tables and did not create any relations.
Try using a key and defining mother tables ?
I am working around a workaround to a "feature" in IBM DB2.
This fancy database has a "feature" in it which if I try to use a CREATE TABLE statement and it doesn't find the schema, it will create this schema for me, even if I don't want it to. This bug has caused me a lot of hours in debugging, because my code right now exists with the expectation that it won't create the schema if it doesn't exist
My question is -- how do I change the permissions of a particular schema (or even during the create schema phase) which a particular user does not have access to view?
I checked out this doc..
It seems with GRANT, there are the following three permissions:
ALTERIN
Grants the privilege to alter or comment on all objects in the
schema. The owner of an explicitly created schema automatically
receives ALTERIN privilege.
CREATEIN
Grants the privilege to create
objects in the schema. Other authorities or privileges required to
create the object (such as CREATETAB) are still required. The owner of
an explicitly created schema automatically receives CREATEIN
privilege. An implicitly created schema has CREATEIN privilege
automatically granted to PUBLIC.
DROPIN
Grants the privilege to drop
all objects in the schema. The owner of an explicitly created schema
automatically receives DROPIN privilege
With only ALTERIN, CREATEIN, and DROPIN, I don't see anything relevant to view access permissions :/
EDIT:
I checked out our Dash DB database for this particular table which has these special permissions for particular users using the following SQL:
SELECT * FROM SYSIBMADM.PRIVILEGES WHERE OBJECTSCHEMA = 'FAKE_SCRATCH';
This is the result:
EDIT 2:
I tried the following to emulate Dash DB's permissions for that user for that schema:
GRANT ALTERIN, CREATEIN, DROPIN ON SCHEMA FAKE_SCRATCH TO USER TEST_USER;
Still doesn't work :/
The following SQL query executed in DB2 fixed the problem:
REVOKE IMPLICIT_SCHEMA ON DATABASE FROM PUBLIC
I am using postgresql. I have created a user and grant access on db. I want user can only see granted schema objects and rest database/schema objects can't watchable. Please guide me.
You need to alter the user and set the search path.
ALTER USER foo SET search_path TO '$newschema,pg_catalog';
Note that in order to get a proper backup of globals such as this you have to use pg_dumpall -g, not pg_dump. Obviously a base backup will have them as well.
We like our production environment with a restricted/unchangable schema -- the development side can be owned by the developers and changed as they like -- and we like to vet changes as they are promoted.
I'm wondering if this may be a solution to making that happen:
postgres% create proddb with owner=postgres;
unixside% pg_restore --dbname=devdb [--schema-only] --no-owner proddb
/* grants to users on schema objects appear to remain intact */
/* here's the magic, I hope... */
postgres% revoke create on schema public from public;
postgres% grant usage on schema public to produser(s);
Some testing seems to show that a user in this new proddb can interact with tables normally (with appropriate grants) and cannot alter the schema (alter table, create table, drop table, etc). But I'm paranoid and very new to Postgres, so...
Q: Is this correct?
Q: Am I missing anything?
Thanks muchly.
Yes, that is correct. The only addition is that the owner of a table can always delete or modify it. So it may not work if you have existing tables in the schema.
Discovered a missing element: sequences.
The user was finding errors in his scripts; similar errors appeared in the logs:
ERROR: permission denied for sequence <sequence>
The production schema showed that although sequences were created, they were owned by postgres and no explicit grants were given to the users. As per the GRANT documentation:
Granting permission on a table does not automatically extend permissions to any sequences used by the table, including sequences tied to SERIAL columns. Permissions on sequence must be set separately.
Our fix (verbose for this demonstration) was to find all sequences:
unixside% pg_dump --schema-only proddb > proddb.schema
unixside% grep -i 'create sequence' proddb.schema
...and apply appropriate grants (select to prevent table scans, update to prevent the above errors):
postgres% grant select,update on <sequence> to produser(s);
So far, the user says it's working and errors to the log have stopped...
I forget what version PostgreSQL added the syntax, but one of the easiest ways to administer permissions in PostgreSQL is through the "GRANT foo, priv ON ALL something IN SCHEMA" syntax.
BEGIN;
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA my_schema TO my_role;
GRANT USAGE ON ALL SEQUENCES IN SCHEMA my_schema TO my_role;
GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA my_schema TO my_role;
COMMIT;
Very handy for making sure that permissions are always set correctly.
The EXECUTE for FUNCTIONS may seem spooky, but shouldn't be unless your functions were created with the SECURITY DEFINER attribute (and if you are using SECURITY DEFINER, you'd better be cautious since you're playing around with the PostgreSQL version of a "setuid" function). If you space out your TABLES across different SCHEMAS based on the expected permissions, then this becomes a pretty handy convention when used with the search_path variable.
ALTER ROLE my_role SET search_path = my_schema, auth_schema, public;
-- Avoid using the public schema (pretty please)
Where auth_schema has a collection of tables that my_role shouldn't have direct read or write privileges on. Assigning privs to GROUPS is also useful.
Here are some relevant docs:
http://developer.postgresql.org/pgdocs/postgres/sql-grant.html
Don't forget you can use "\h GRANT" in psql to easily figure out the syntax or remember what can be done on all objects in a schema (search for "IN SCHEMA").