According to my understanding of the PostgreSQL documentation, the role "pg_read_all_data" should grant the role holder the ability to execute "Select * from SCHEMA.TABLE" and similar to view the data. However, I'm unsure why this is not working out in practice for me.
I have created a sample schema and database on account "X" for example:
Image showing schema and table structure
However, when I log into role "Y" (with log in option enabled) with the role "pg_read_all_data" and try to execute:
SELECT * FROM test.test_table
Edit: I have assigned the role "pg_read_all_data" via the command: GRANT pg_read_all_data to "Y" on a superuser role.
It throws a permission error: SQL Error [42501]: ERROR: permission denied for schema test
Position: 15
I'm a little lost on why this is the case when the role should've granted select privileges. Can someone tell me why this is happening?
Closed - After a few days away, I went back to the issue and it seemed to have resolved itself.
Related
I've been working on maintenance on this GitHub repo that has been left undeveloped for almost a year. When rerunning the GitHub Actions job that finished to completion last May, there are now issues related to permission for CREATE in the public schema in PostgreSQL. At first I suspected, this might be because of the recent PostgreSQL 15 update that made it so that users do not by default have create access on the public schema. However, for our job GitHub Actions uses Postgres 14 for Ubuntu 22.04 (postgresql_14+238), so this change to public schema access in PostgreSQL shouldn't be affecting us. Our previous passing run used Postgres 12 for Ubuntu 20.04 (postgresql-12_12.10-0ubuntu0.20.04.1), so the changed environment could still be relevant.
The job is erroring out during a step where we create a few tables within our database using <user>:
peewee.ProgrammingError: permission denied for schema public
LINE 1: CREATE TABLE IF NOT EXISTS "articles" ("id" INTEGER NOT NULL...
Before this step, we configure the PostgreSQL database, creating the <user> and granting it all permissions to the database: `
CREATE USER <user>;
GRANT ALL PRIVILEGES ON DATABASE <db_name> to <user>
To remedy this problem (while still being confused on why it arose), I tried to explicitly grant <user> permissions on the public schema before attempting any CREATEs following the suggestions from this post: https://www.cybertec-postgresql.com/en/error-permission-denied-schema-public/
GRANT ALL ON SCHEMA public TO <name>;
which seems to go through based on the returned GRANT .
Locally, I'm having no issues with permissions even without the GRANT using PostgreSQL 14, but the permission error still comes up on GitHub Actions, even after granting access to the public schema to the user (and in a desperate attempt--to all users).
I've done a bunch of sanity checks related to making sure that we are in fact using the <user> during the CREATE step, but it seems like the <user> just never ends up getting the permissions even after the GRANT. I followed postgresql - view schema privileges to view schema privileges, and locally, the <user> has permissions to the public schema even before the GRANT. However, on GitHub Actions, the <user> doesn't have permissions before nor after the GRANT, even though there is output confirmation that the GRANT completed successfully.
Does anyone know why I would be having these permission errors now on GitHub Actions, despite the code working locally and on GitHub Actions months ago? Is there any way I can grant permissions differently that might work better in this environment?
The permissions on schema public changed in v15. This change finally got rid of the insecure default setting of letting every user create objects in that schema. Now only the database owner is allowed to create objects by default.
Your GRANT statement is good to allow a user to create objects in schema public:
GRANT CREATE ON SCHEMA public TO user_that_creates_objects;
Just remember that you have to connect to the target database before running that statement. Also, the GRANT must be executed by the database owner or a superuser.
My recommendation is to leave the public schema for extension objects and create your own schema for your application objects.
I'm trying to follow this article to enable the pg_cron extension on my postgres RDS instance on AWS:
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL_pg_cron.html
it says to run on the rds_superuser
CREATE EXTENSION pg_cron;
However, I'm logged in under a different user, I don't currently have access to the rds_superuser account. The message I get is:
SQL Error [42501]: ERROR: permission denied to create extension "pg_cron"
Hint: Must be superuser to create this extension.
Can anyone please tell me a work-around for this without having to contact a DBA? Can I grant superuser or create a new user with superuser to get around this?
it looks like the current user I have access to only shows on the pg_tables access to:
rolinherit - X
rolcanlogin - X
Ok I found out that if you go to your RDS database instance on AWS, you can "Modify" the RDS instance, and change the master password for the sysadmin user. I was then able sign in with this user and do what I needed to do.
I'm trying to set up a Datadog PostgreSQL integration that requires a user with pg_monitor role and SELECT permission on pg_stat_database as described on their own documentation.
My database is currently hosted on Heroku and it seems the default user doesn't have SUPERUSERpermissions because, when I try to apply the above role and permission to a "monitor" user I have the following error message:
ERROR: must have admin option on role "pg_monitor"
So I'm looking for some way of:
grant the necessary permissions to that user without being a superuser
get superuser access on Heroku Postgres (what I think is not possible)
Someone has ever faced this issue? There is a way to handle this case?
I had to open a ticket asking the Heroku CS team to apply the "pg_monitor" role to my user. They've granted the role and now everything is working fine
I have created a user role cadmin. When logged in as cadmin, I create a schema and create tables in the schema. This is with postgress 9.3
I am able to access the schema and query the tables perfectly fine from a tool like TOAD. However, from an application connected to the database, i always get an error that "permission is denied to the schema'. In the same application, I use jooq and that using the same role and the schema is able to find all the tables and create the classes. Just that when I do a 'Select' i get the error.
"nested exception is org.postgresql.util.PSQLException: ERROR: permission denied for schema core_engine"
You need to grant the permission for schema. So, you could try using following query from tool like TOAD and then run the application
GRANT USAGE ON SCHEMA schema_name TO postgres_user_name;
Yesterday I created a user to make backups from PostgreSQL. I granted select to this user and then I noticed that the name was not well written. The problem is that I tried to erase the user using the command line and the response was, due to the grants that I made a few moments back:
ERROR: role "dump_user" cannot be dropped because some objects depend on it
Long story short, I erased this user using pgadmin and now I have problems because when I want to create a new table, it tells:
ERROR: role 313898229 was concurrently dropped
I cheked and 313898229 was the oid of this dump_user in the pg_authid table, I tried to create a new user and assign this oid, but postgres says that I can't modify system id "oid".
Is there a way that I can permanently erase this user?
If all you wanted was a different name:
ALTER ROLE dump_user RENAME TO better_name;
Too late for that now. Before deleting the role you should have run:
REASSIGN OWNED BY pg_dump TO postgres; -- postgres being default superuser role
Read details here:
Find objects linked to a PostgreSQL role
Your error message:
ERROR: role 313898229 was concurrently dropped
is defined in the source code here. Looks like a race condition between two transactions. But you omitted relevant details.