Re: Open items

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > Here's the results of this. I think we're pretty close to having both
> > "Basic roles" and "Extended roles" personally. For 'Basic roles' we
> > need SET ROLE and some information schema tables.
>
> The information schema views already exist, although I suspect the view
> definitions may need more work.

Ok.

> > REVOKE ROLE w/CASCADE drop behavior.
>
> I was just about to quiz you about the lack of any use of the grantor
> column in pg_auth_members. I suppose that revoking a membership that
> was held WITH ADMIN OPTION ought to lead to searching for and destroying
> all memberships granted by that ID (possibly indirectly?). DROP ROLE
> has got the same problem.

Not sure about indirectly, but I think a 'drop role' should check for
existing entries where that role is the 'grantor' and fail if any exist
unless 'cascade' is given. I think 'drop role' at one point (when it
was still seq-scan based) dropped based on the 'grantor' field
(regardless of 'cascade' or not). When I converted it to using an index
apparently I missed that issue, sorry about that. Seems like that'd
mean it'd have to go back to seq-scan based again. :/

> Also, I've been working on converting the CREATEROLE privilege into
> something usable, and am about ready to commit that. The way it works
> is that CREATEROLE lets you do anything that user.c formerly required
> superuser for, *except* that you have to be superuser to mess with
> superuser roles in any way. This all seems fine as far as it goes,
> but should revoking CREATEROLE lead to dropping grants that were made
> by means of that power? Not sure. We ended up with some fairly
> carefully crafted compromises for ACL representation of grants made
> by superusers, and I think we'll likely need to think hard about it
> for role memberships too.

I'd tend to think that revoking CREATEROLE wouldn't drop grants which
were made using it. I do agree that it needs to be thought out more
carefully than I believe it has been so far though.

Thanks,

Stephen