Re: [PATCH v2] use has_privs_for_role for predefined roles - Mailing list pgsql-hackers

From Joe Conway
Subject Re: [PATCH v2] use has_privs_for_role for predefined roles
Date
Msg-id 18eab9b6-1f77-72b2-83d3-1856c17f3fcb@joeconway.com
Whole thread Raw
In response to Re: [PATCH v2] use has_privs_for_role for predefined roles  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [PATCH v2] use has_privs_for_role for predefined roles  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 2/7/22 12:09, Robert Haas wrote:
> On Mon, Feb 7, 2022 at 11:13 AM Joe Conway <mail@joeconway.com> wrote:
>> It is confusing and IMHO dangerous that the predefined roles currently
>> work differently than regular roles eith respect to privilege inheritance.
> 
> I feel like that's kind of a conclusory statement, as opposed to
> making an argument. I mean that this tells me something about how you
> feel, but it doesn't really help me understand why you feel that way.


The argument is that we call these things "predefined roles", but they 
do not behave the same way normal "roles" behave.

Someone not intimately familiar with that fact could easily make bad 
assumptions, and therefore wind up with misconfigured security settings. 
In other words, it violates the principle of least astonishment (POLA).

As Joshua said nearby, it simply jumps out at me as a bug.

-------
After more thought, perhaps the real problem is that these things should 
not have been called "predefined roles" at all. I know, the horse has 
already left the barn on that, but in any case...

They are (to me at least) similar in concept to Linux capabilities in 
that they allow roles other than superusers to do a certain subset of 
the things historically reserved for superusers through a special 
mechanism (hardcoded) rather than through the normal privilege system 
(GRANTS/ACLs).

As an example, the predefined role pg_read_all_settings allows a 
non-superuser to read GUC normally reserved for superuser access only.

If I create a new user "bob" with the default INHERIT attribute, and I 
grant postgres to bob, bob must SET ROLE to postgres in order to access 
the capability to read superuser settings.

This is similar to bob's access to the default superuser privilege to 
read data in someone else's table (must SET ROLE to access that capability).

But it is different from bob's access to inherited privileges which are 
GRANTed:
8<--------------------------
psql nmx
psql (15devel)
Type "help" for help.

nmx=# create user bob;
CREATE ROLE

nmx=# grant postgres to bob;
GRANT ROLE

nmx=# \q
8<--------------------------
-and-
8<--------------------------
psql -U bob nmx
psql (15devel)
Type "help" for help.

nmx=> select current_user;
  current_user
--------------
  bob
(1 row)

nmx=> show stats_temp_directory;
ERROR:  must be superuser or have privileges of pg_read_all_settings to 
examine "stats_temp_directory"
nmx=> set role postgres;
SET
nmx=# show stats_temp_directory;
  stats_temp_directory
----------------------
  pg_stat_tmp
(1 row)

nmx=# select current_user;
  current_user
--------------
  postgres
(1 row)

nmx=# select * from foo;
  id
----
  42
(1 row)

nmx=# reset role;
RESET
nmx=> select current_user;
  current_user
--------------
  bob
(1 row)

nmx=> select * from foo;
ERROR:  permission denied for table foo
nmx=> set role postgres;
SET
nmx=# grant select on table foo to postgres;
GRANT
nmx=# reset role;
RESET
nmx=> select current_user;
  current_user
--------------
  bob
(1 row)

nmx=> select * from foo;
  id
----
  42
(1 row)
8<--------------------------

Joe

-- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Database-level collation version tracking
Next
From: Antonin Houska
Date:
Subject: Temporary file access API