Clarity Bug for Schema Permissions, Potential Vulnerability? - Mailing list pgsql-bugs

From Justis Lincoln Mackaoui
Subject Clarity Bug for Schema Permissions, Potential Vulnerability?
Date
Msg-id BYAPR08MB47114B0C6363EB31732B27B5D1A70@BYAPR08MB4711.namprd08.prod.outlook.com
Whole thread Raw
Responses Re: Clarity Bug for Schema Permissions, Potential Vulnerability?  (Oleksandr Shulgin <oleksandr.shulgin@zalando.de>)
Re: Clarity Bug for Schema Permissions, Potential Vulnerability?  ("David G. Johnston" <david.g.johnston@gmail.com>)
List pgsql-bugs

Hi there,

 

There’s an issue with the consistency of “ERROR: permission denied” which is a small gotcha for new Postgres users like myself. It may be desirable behavior but please bear with me.

 

Here’s a scenario displaying the current behavior in PostgreSQL 11.5:

  1. The database has two schemas, “public” and “test”.
  2. The database has two users, “admin” and “test_user”.
  3. Admin user runs a variation of “CREATE SCHEMA test_schema”
  4. Admin user runs “CREATE TABLE test_schema.test_table”

 

  1. Test_user runs “SELECT * FROM test_schema.test_table”, receives “ERROR: permission denied” (as expected).
  2. Admin runs “GRANT ALL PRIVILEGES ON test_schema.test_table TO test_user”, receives “Query returned successfully”
  3. Test user runs “SELECT * FROM test_schema.test_table”, receives “ERROR: permission denied”

---

If you now check the permissions on “test_table”, you’ll see that it correctly granted all privileges to “test_user”, despite throwing errors when “test_user” attempts to access it; this is the source of confusion. Experienced users will know that you must FIRST run “GRANT USAGE ON SCHEMA test_schema TO test_user”, so that the user has access to the schema.

 

My argument is that step #6, the granting of privileges on the table, should return an “ERROR: permission denied” because the “test_user” should not know at all about the objects contained within “test_schema”. This would prevent the confusing state of contradictory permissions and access-errors.

---

 

This problem with contradictory permissions and access-errors is relatively minor and can be fixed by the user with a little playing around, however I’m curious if it might expose any real vulnerabilities. It seems as though the driver only validates the permissions of the logged-in user “admin”, who does have access to the schema “test_schema” as well as “test_table”, and not the permissions of “test_user”.

 

My suggestion is that the separation of permissions between Database/Schema/Table/User be respected equally by the driver, in the sense that both the logged-in user and any user-object pair in the expression have the same permission validation ran against them.

 

I’m no security specialist or expert on PostgreSQL’s source code, but I worry that someone who IS might come up with a strategy to exploit this behavior.

 

Thank you for your work,

Justis Mackaoui

 

New PostgreSQL user

 

 

 

pgsql-bugs by date:

Previous
From: Andreas Seltenreich
Date:
Subject: Re: BUG #16393: PANIC: cannot abort transaction, it was already committed
Next
From: Sandeep Thakkar
Date:
Subject: Re: BUG #16416: unable to start the server with pg_CTL