Re: replacing role-level NOINHERIT with a grant-level option

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>
To: tushar <tushar.ahuja@enterprisedb.com>
Cc: Nathan Bossart <nathandbossart@gmail.com>, Joe Conway <mail@joeconway.com>, Tom Lane <tgl@sss.pgh.pa.us>, "Bossart, Nathan" <bossartn@amazon.com>, Stephen Frost <sfrost@snowman.net>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2022-07-28T14:33:08Z
Lists: pgsql-hackers
On Thu, Jul 28, 2022 at 10:16 AM tushar <tushar.ahuja@enterprisedb.com> wrote:
> On 7/19/22 12:56 AM, Robert Haas wrote:
> > Another good catch. Here is v5 with a fix for that problem.
> Here is one scenario in which I have NOT granted (inherit false)
> explicitly but still revoke
> command is changing the current state
>
> postgres=# create group foo;
> CREATE ROLE
> postgres=# create user bar in group foo;
> CREATE ROLE
> postgres=# revoke inherit option for foo from bar;
> REVOKE ROLE
>
> [edb@centos7tushar bin]$ ./pg_dumpall > /tmp/a11
>
> [edb@centos7tushar bin]$ cat /tmp/a11 |grep 'inherit false' -i
> GRANT foo TO bar WITH INHERIT FALSE GRANTED BY edb;
>
> I think this revoke command should be ignored and inherit option should
> remain 'TRUE'
> as it was before?

No, it seems to me that's behaving as intended. REVOKE BLAH OPTION ...
is intended to be a way of switching an option off.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Fix a bug in roles_is_member_of.

  2. docs: Fix up some out-of-date references to INHERIT/NOINHERIT.

  3. Allow grant-level control of role inheritance behavior.

  4. Make role grant system more consistent with other privileges.

  5. Document basebackup_to_shell.required_role.