From: | PG Bug reporting form <noreply(at)postgresql(dot)org> |
---|---|
To: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Cc: | snaperling(at)gmail(dot)com |
Subject: | BUG #18639: Unexpected behavior with SET ROLE and CREATE ROLE interaction |
Date: | 2024-09-27 23:33:46 |
Message-ID: | 18639-d7908c6b789395b5@postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
The following bug has been logged on the website:
Bug reference: 18639
Logged by: Luis Couto
Email address: snaperling(at)gmail(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Guo | 2024-09-28 00:39:53 | Re: BUG #18634: Wrong varnullingrels with merge ... when not matched by source |
Previous Message | Laurenz Albe | 2024-09-27 18:00:30 | Re: BUG #18638: PANIC: could not open file "pg_logical/snapshots/B6-9EE5B820.snap": Permission denied |