How do I resolve a "permission denied for schema public" error for PostgreSQL on GitHub Actions? - postgresql

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.

Related

Postgres: prevent new user from creating tables, without superuser

In Cloud SQL Postgres, where superuser permissions are not accessible, how can I prevent a new user from creating tables?
I know that REVOKE CREATE ON SCHEMA public FROM public works, but this seem to require superuser permissions, as I get a WARNING: no privileges could be revoked for "public" error.
You have to run that statement as the user who owns public.

Can't create new schema in an OVH postgres

I have a PostgreSQL server on OVH's Cloud DB and have been using its databases for my web apps.
So far so good.
I got a project where It's a requirement to have schemas. Strangely enough, I am unable to create schemas on the user with "Administrator" privileges.
I have prepared scripts using schemas, so I just need to run them on a prepared database but I need a database with schemas to run them.
Here is my process:
Create a new database
Select option "Create user"
Select option for privilages: "Administrator"
Commit configuration
Wait for database creation
Connect to database with the new config via PGAdmin
Run command create schema if not exists "vMobile";
Recieve following error:
ERROR: permission denied for database my-database-dev
SQL state: 42501
I created a ticket for this but the wait is taking too long.
Support answer
Ok, so I got a response from the OVH support and there is no option for the user to create new schemas as their CloudDB enables access only to schema public and mentioned privileges Administrator, Read/Write, Read, None are only applicable to the public schema.
Workaround
My solution to this is to create tables with schema name included in their names
like so:
Desired outcome: "vCommon"."Route"
Workaround: "public"."vCommon_Route"

Permission denied to copy database

I'm still getting used to the concept of roles in Postgres.
I'm trying to create a role, migrator, that will have the ability to read from a production db and use it as a template to make stage and dev databases.
I've created this role migrator originally like so:
CREATE ROLE migrator LOGIN ENCRYPTED PASSWORD '<password>'
and proceeded to restrict access to the prod database:
REVOKE ALL ON DATABASE prod FROM PUBLIC;
GRANT CONNECT ON DATABASE prod TO migrator;
/* switch to prod database */
GRANT USAGE ON SCHEMA public TO migrator;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO migrator;
GRANT SELECT ON ALL SEQUENCES IN SCHEMA public TO migrator;
After trying a CREATE DATABASE stage TEMPLATE prod; and getting an error, I had to alter the role to create a db:
ALTER ROLE migrator CREATEDB;
and tried again. This time I got the error:
ERROR: permission denied to copy database "prod"
And again, I tried to add the replication permission to the migrator role (not sure if this is correct, as the manual says this is a very elevated permission)
ALTER ROLE migrator REPLICATION;
however, I still get the same error.
UPDATE: I've figured out that this has something to do with who owns the database; however, my problem remains. How can I allow another role with just READ privileges the ability to copy a database as well? I looked at role inheritance, but at first glance it looks like the inheriting role will just get the same permissions as the parent role.
It's not possible to copy a database unless the logged-in role is an owner or the database is flagged as a template:
datistemplate can be set to indicate that a database is intended as a template for CREATE DATABASE. If this flag is set, the database can be cloned by any user with CREATEDB privileges; if it is not set, only superusers and the owner of the database can clone it.

Using Postgres PGCrypto encryption requires superuser to run view queries

Using: Postgres 9, CentOS 7,
Postgres Data directory not in default location but used RSync to make sure permissions were correct. And yes appropriate .config files were changed.
When I try to query a view containing an encrypted item as a NON superuser (Testuser), I get this error:
ERROR: must be superuser to read files CONTEXT: PL/pgSQL function
decrypt_data(bytea) line 13 at assignment
If I run that same query using POSTGRES superuser, the query completes fine.
This seems to be a file system read permission error when trying to read the Key files. Everything I see using encryption seem to not mention how to run without being superuser.
I have already run the following grants for Testuser:
GRANT ALL PRIVILEGES ON DATABASE xxx_db to Testuser;
GRANT SELECT ON ALL TABLES IN SCHEMA xxxxx TO Testuser;
GRANT ALL ON ALL TABLES IN SCHEMA xxxxx TO Testuser;
The test user can create tables, views, basically anything within that db.. just not read encryption keys.
The permissions on the keys are 775 right now, I even tried 777 without luck.
Any Ideas?
pgcrypto is a PostgreSQL extension described here:
https://www.postgresql.org/docs/current/static/pgcrypto.html
but it doesn't provide a decrypt_data(bytea) function.
This function seems to be custom code that happens to open a server-side file, with pg_read_file() or a similar method.
These methods are restricted to superusers to avoid normal users to read on the server's filesystem, no matter what are the Unix rights of the particular file they want to read.
You can verify this in the source of decrypt_data(bytea), which can be obtained with:
select pg_get_functiondef('decrypt_data(bytea)'::regprocedure);
or \df+ decrypt_data(bytea) from within psql.
I found the issue. I need to grant the user with function permissions.
GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA xxxxx TO yyyyyyyyy;

Postgres ACL for Schemas

I'm not a DBA and I have got some questions around access controls for schemas. Let's say I have a Postgres server running a several databases. The admin user is postgres. I have another user tmpUser with which I could log in to the remote server using pgadmin3 client.
I now create a database called myDatabase which is by default owned by the postgres user. I then use my admin client to remotely log in to this myDatabase using the tmpUser account.
I now create a new schema inside this myDatabase called myDbSchema. I created a new role called myDbRole and did a grant usage, grant all on myDatabase, myDbSchema to the myDbRole.
The question now is how should I control access to this myDatabase. I tried to log in to the remote server using the tmpUser and when I tried to execute select * from myTable where myTable is a table in myDatabase, it came back with a permission denied sql message. So I changed the owner of the table to the tmpUser which I really do not want to!
Is there a guide or something on how I should go about creating and organizing roles with schemas in postgres?
It is not entirely clear what your problem is (for instance, what is role "myDbRole" for, is that a group role (NOLOGIN) or a user role (LOGIN)?) but in general you could follow this pattern of permission management:
Create a specific role to own a database and all or most of the objects in it. This should be a group role (NOLOGIN) for security reasons. Do not use the postgres user; if you need to login as that role often to do regular database work, you are doing something wrong. Any superuser (or other user role that has that role granted to it) can "impersonate" that owner role using SET SESSION AUTHORIZATION to do necessary maintenance. In a production environment this should be hardly ever necessary; during development you might want to consider making the role with LOGIN permission for ease of use.
The owner creates all the schemas, tables, views, functions, etc. that you need for your application. By default, all of those objects are only available to the database owner, with the exception of functions.
Define a number of group role profiles, each having specific requirements of the database. You could have, for instance sales_staff, product_managers, accounting and senior_management for a company, or web_user, web_admin, app_developer and app_manager for a web site. The database owner then GRANTs access to the database (CONNECT), schemas (USAGE), tables, views and functions (EXECUTE), as needed. I usually REVOKE ALL ON FUNCTION x() TO public, for security reasons.
Assign group role membership to user roles, as needed: GRANT sales_staff TO jane. The user roles should have LOGIN INHERIT such that they can log in and inherit the permission of group roles that they are a member of. That includes the permission to connect to a database and usage rights on schemas. Note that a single user role can have membership in multiple group roles.
Lastly, update your pg_hba.conf file to enable remote access to the database.