public inbox for [email protected]help / color / mirror / Atom feed
Re: v16 roles, SET FALSE, INHERIT FALSE, ADMIN FALSE 3+ messages / 3 participants [nested] [flat]
* Re: v16 roles, SET FALSE, INHERIT FALSE, ADMIN FALSE @ 2024-07-08 21:16 Tom Lane <[email protected]> 0 siblings, 2 replies; 3+ messages in thread From: Tom Lane @ 2024-07-08 21:16 UTC (permalink / raw) To: Pavel Luzanov <[email protected]>; +Cc: Christophe Pettus <[email protected]>; pgsql-general Pavel Luzanov <[email protected]> writes: > On 08.07.2024 22:22, Christophe Pettus wrote: >> This is more curiosity than anything else. In the v16 role system, is there actually any reason to grant membership in a role to a different role, but with SET FALSE, INHERIT FALSE, and ADMIN FALSE? Does the role granted membership gain any ability it didn't have before in that case? > Looks like there is one ability. > Authentication in pg_hba.conf "USER" field via +role syntax. Hmm, if that check doesn't require INHERIT TRUE I'd say it's a bug. regards, tom lane ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: v16 roles, SET FALSE, INHERIT FALSE, ADMIN FALSE @ 2024-07-08 21:23 Pavel Luzanov <[email protected]> parent: Tom Lane <[email protected]> 1 sibling, 0 replies; 3+ messages in thread From: Pavel Luzanov @ 2024-07-08 21:23 UTC (permalink / raw) To: Tom Lane <[email protected]>; +Cc: Christophe Pettus <[email protected]>; pgsql-general On 09.07.2024 00:16, Tom Lane wrote: > Pavel Luzanov<[email protected]> writes: >> On 08.07.2024 22:22, Christophe Pettus wrote: >>> This is more curiosity than anything else. In the v16 role system, is there actually any reason to grant membership in a role to a different role, but with SET FALSE, INHERIT FALSE, and ADMIN FALSE? Does the role granted membership gain any ability it didn't have before in that case? >> Looks like there is one ability. >> Authentication in pg_hba.conf "USER" field via +role syntax. > Hmm, if that check doesn't require INHERIT TRUE I'd say it's > a bug. > > regards, tom lane My test scenario: postgres@demo(16.3)=# select * from pg_hba_file_rules ; rule_number | file_name | line_number | type | database | user_name | address | netmask | auth_method | options | error -------------+-------------------------------------+-------------+-------+----------+------------+---------+---------+-------------+---------+------- 1 | /etc/postgresql/16/main/pg_hba.conf | 118 | local | {all} | {postgres} | | | trust | | 2 | /etc/postgresql/16/main/pg_hba.conf | 121 | local | {all} | {+bob} | | | trust | | 3 | /etc/postgresql/16/main/pg_hba.conf | 122 | local | {all} | {alice} | | | reject | | (3 rows) postgres@demo(16.3)=# \drg List of role grants Role name | Member of | Options | Grantor -----------+-----------+---------+---------- alice | bob | | postgres (1 row) postgres@demo(16.3)=# \c - alice You are now connected to database "demo" as user "alice". alice@demo(16.3)=> -- Pavel Luzanov Postgres Professional:https://postgrespro.com ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: v16 roles, SET FALSE, INHERIT FALSE, ADMIN FALSE @ 2024-07-08 21:59 David G. Johnston <[email protected]> parent: Tom Lane <[email protected]> 1 sibling, 0 replies; 3+ messages in thread From: David G. Johnston @ 2024-07-08 21:59 UTC (permalink / raw) To: Tom Lane <[email protected]>; +Cc: Pavel Luzanov <[email protected]>; Christophe Pettus <[email protected]>; pgsql-general On Mon, Jul 8, 2024 at 2:16 PM Tom Lane <[email protected]> wrote: > Pavel Luzanov <[email protected]> writes: > > On 08.07.2024 22:22, Christophe Pettus wrote: > >> This is more curiosity than anything else. In the v16 role system, is > there actually any reason to grant membership in a role to a different > role, but with SET FALSE, INHERIT FALSE, and ADMIN FALSE? Does the role > granted membership gain any ability it didn't have before in that case? > > > Looks like there is one ability. > > Authentication in pg_hba.conf "USER" field via +role syntax. > > Hmm, if that check doesn't require INHERIT TRUE I'd say it's > a bug. > > The code doesn't support that claim. It seems quite intentional that this check is purely on membership - what with ACL having a dedicated function for the purpose of checking plain recursive membership that only this and the circularity check code use. I suppose it makes sense too - at least unless you also check for SET - since it seems desirable to allow login as a member role to a group you can only SET to and don't inherit from. David J. ^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2024-07-08 21:59 UTC | newest] Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2024-07-08 21:16 Re: v16 roles, SET FALSE, INHERIT FALSE, ADMIN FALSE Tom Lane <[email protected]> 2024-07-08 21:23 ` Pavel Luzanov <[email protected]> 2024-07-08 21:59 ` David G. Johnston <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox