Re: Open items
От | Tom Lane |
---|---|
Тема | Re: Open items |
Дата | |
Msg-id | 15499.1120076207@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Open items (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: Open items
|
Список | pgsql-hackers |
Stephen Frost <sfrost@snowman.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. > For 'Extended roles' > I think we need '<default option> CURRENT_ROLE' (if this isn't already > taken care of because CURRENT_ROLE is a function?), Yes, it is. > 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. 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. regards, tom lane
В списке pgsql-hackers по дате отправления: