RE: New predefined roles- 'pg_read/write_all_data' - Mailing list pgsql-hackers

From Shinoda, Noriyoshi (PN Japan FSIP)
Subject RE: New predefined roles- 'pg_read/write_all_data'
Date
Msg-id TU4PR8401MB1152491214E4858079A734E8EED19@TU4PR8401MB1152.NAMPRD84.PROD.OUTLOOK.COM
Whole thread Raw
In response to Re: New predefined roles- 'pg_read/write_all_data'  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers

Thank you for your quick response.

I understood the specifications from your explanation.

 

Regards,

Noriyoshi Shinoda

 

From: Stephen Frost [mailto:sfrost@snowman.net]
Sent: Sunday, September 5, 2021 8:50 PM
To: Shinoda, Noriyoshi (PN Japan FSIP) <noriyoshi.shinoda@hpe.com>
Cc: Anastasia Lubennikova <a.lubennikova@postgrespro.ru>; Michael Banck <michael.banck@credativ.de>; gkokolatos@pm.me; pgsql-hackers@lists.postgresql.org
Subject: Re: New predefined roles- 'pg_read/write_all_data'

 

Greetings,

 

On Sun, Sep 5, 2021 at 07:43 Shinoda, Noriyoshi (PN Japan FSIP) <noriyoshi.shinoda@hpe.com> wrote:

I have tested this new feature with PostgreSQL 14 Beta 3 environment.
I created a user granted with pg_write_all_data role and executed UPDATE and DELETE statements on tables owned by other users.
If there is no WHERE clause, it can be executed as expected, but if the WHERE clause is specified, an error of permission denied will occur.
Is this the expected behavior?

 

A WHERE clause requires SELECT rights on the table/columns referenced and if no SELECT rights were granted then a permission denied error is the correct result, yes. Note that pg_write_all_data, as documented, does not include SELECT rights. 

 

Thanks,

 

Stephen

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCH] postgres_fdw: suppress explicit casts in text:text comparisons (was: column option to override foreign types)
Next
From: Michael Paquier
Date:
Subject: Timeout failure in 019_replslot_limit.pl