Re: Default Roles - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Default Roles
Date
Msg-id CAB7nPqT9RA-+rRAy7t91adt4soTX0TXL04MNkQRK5fAKP6egvQ@mail.gmail.com
Whole thread Raw
In response to Re: Default Roles  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
On Mon, Apr 18, 2016 at 12:05 PM, Noah Misch <noah@leadboat.com> wrote:
> On Sun, Apr 17, 2016 at 08:04:03PM -0400, Noah Misch wrote:
>> On Thu, Apr 07, 2016 at 03:50:47PM -0400, Stephen Frost wrote:
>> > I'm planning to continue going over the patch tomorrow morning with
>> > plans to push this before the feature freeze deadline.
>>
>> > --- a/src/test/regress/expected/rolenames.out
>> > +++ b/src/test/regress/expected/rolenames.out
>>
>> > +GRANT testrol0 TO pg_abc; -- error
>> > +ERROR:  role "pg_abc" is reserved
>> > +DETAIL:  Cannot GRANT roles to a reserved role.
>>
>> The server still accepts "ALTER ROLE testrol0 USER pg_signal_backend".  It
>> should block this ALTER ROLE if it blocks the corresponding GRANT.

Following this logic, shouldn't CREATE ROLE USER be forbidden as well?
=# create role toto1 user pg_signal_backend;
CREATE ROLE
=# create role toto2;
CREATE ROLE
=# alter role toto2 user pg_signal_backend;
ALTER ROLE
=# \dgS+ pg_signal_backend
                         List of roles
     Role name     |  Attributes  |   Member of   | Description
-------------------+--------------+---------------+-------------
 pg_signal_backend | Cannot login | {toto1,toto2} |

In short a reserved role should never be member of another role/group,
as per the attached.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: Pgbench with -f and -S
Next
From: Fujii Masao
Date:
Subject: Re: checkpoint_flush_after documentation inconsistency