Alvaro Herrera <alvherre@commandprompt.com> writes:
> So I'm currently considering the following alternatives:
> 1. do nothing at all with pg_shdepend. Upon role deletion, seqscan
> pg_auth_members and reject the drop altogether if there is a role
> granted to another which mentions the to-be-dropped role ID as grantor.
> This is easiest in terms of code (it's even mentioned in the comments in
> DropRole).
> 2. record one pg_shdepend entry for each role that has granted something
> to each role (unless the grantor is the same role being granted, in
> which case we needn't record anything). So if role A grants Z and X to
> C, and role B grants Y and W to C, C now has access to W, Y, X and Z and
> there are two pg_shdepend entries:
> C -> A
> C -> B
> So dropping a role would be disallowed automatically without any code
> changes, with the checkSharedDependencies() call that's already in
> DropRole. Adding a role membership would require a bit more work,
> because we'd first need to check that there's not already a pg_shdepend
> entry for that combination. Removing a role membership also becomes
> more work; we need to check that no other grant depends on the same
> grantor before removing the entry.
Both of these have got race conditions ... not but what the dependency
code has got race condition problems already, but maybe we should try
to avoid introducing more? I haven't got any better ideas though.
Why is it that we record grantor at all? One could argue that granting
membership in a role is done on behalf of that role and there's no real
need to remember exactly who did it.
regards, tom lane
