On 3/22/16 10:35 PM, Kyotaro HORIGUCHI wrote:
Even if we maintained some interlock for a backend's login role identity,
>I hardly think it would be practical to e.g. lock during transient SET
>ROLE or security-definer-function-call operations. So it's not like we
>can let the permissions system assume that a role OID being inquired about
>always matches a live entry in pg_authid.
Even if blocking DROPs is not perfect for all cases,
unconditionally allowing to DROP a role still doesn't seem proper
behavior, especially for replication roles. And session logins
seem to me to have enough reason to be treated differently than
disguising as another role using SET ROLE or sec-definer.
There's probably a way this could be handled, since DROP ROLE is
presumably a very uncommon operation. Perhaps something as simple as
keeping a single OID in shared memory for the role about to be dropped.
That would serialize role drops, but I doubt that matters.
The attached patch blocks DROP ROLE for roles that own active
sessions, and on the other hand prevents a session from being
activated if the login role is concurrently dropped.
I think this is fine for now, but... what happens if you drop a role
that's in use on a streaming replica? Does replay stall or do we just
ignore it?
There should probably be some doc changes to go with the patch too, no?
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
