On Mon, Apr 18, 2016 at 12:05 PM, Noah Misch <n...@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
catalog-acl-group.patch
Description: application/download
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
