Thread: BUG #18639: Unexpected behavior with SET ROLE and CREATE ROLE interaction
BUG #18639: Unexpected behavior with SET ROLE and CREATE ROLE interaction
From
PG Bug reporting form
Date:
The following bug has been logged on the website: Bug reference: 18639 Logged by: Luis Couto Email address: snaperling@gmail.com PostgreSQL version: 16.4 Operating system: Windows Any Description: I've observed an unexpected behavior when using SET ROLE in combination with CREATE ROLE in PostgreSQL. I'd like to confirm if this is intended behavior or if it's an undocumented side effect. The scenario: 1. User A sets their role to Role B using SET ROLE. 2. While acting as Role B, User A creates a new Role C using CREATE ROLE. 3. Unexpectedly, Role B becomes a member of the newly created Role C. Example: SET ROLE admin_role; CREATE ROLE new_user WITH PASSWORD 'password'; In this case, admin_role becomes a member of new_user. This automatic membership assignment seems to prevent adding new_user to the admin_role group later on. Questions: 1. Is this behavior intentional or documented anywhere? 2. If intentional, what's the rationale behind this automatic membership assignment? 3. Are there any recommended best practices to avoid this when creating roles? I couldn't find any documentation explicitly mentioning this behavior, so I'd appreciate any insights or clarification on this matter.
Re: BUG #18639: Unexpected behavior with SET ROLE and CREATE ROLE interaction
From
"David G. Johnston"
Date:
On Friday, September 27, 2024, PG Bug reporting form <noreply@postgresql.org> wrote:
The following bug has been logged on the website:
Bug reference: 18639
Logged by: Luis Couto
Email address: snaperling@gmail.com
PostgreSQL version: 16.4
Operating system: Windows Any
Description:
I've observed an unexpected behavior when using SET ROLE in combination with
CREATE ROLE in PostgreSQL. I'd like to confirm if this is intended behavior
or if it's an undocumented side effect.
Yes, this was part of making the usage of the create role attribute more secure.
See related discussion here:
David J.