Re: Why is_admin_of_role() use ROLERECURSE_MEMBERS rather than ROLERECURSE_PRIVS?
| От | cca5507 |
|---|---|
| Тема | Re: Why is_admin_of_role() use ROLERECURSE_MEMBERS rather than ROLERECURSE_PRIVS? |
| Дата | |
| Msg-id | tencent_89E0A11CDCDB6586E615E6D4CAA610CBEC0A@qq.com обсуждение исходный текст |
| Ответ на | Why is_admin_of_role() use ROLERECURSE_MEMBERS rather than ROLERECURSE_PRIVS? ("cca5507" <cca5507@qq.com>) |
| Ответы |
Re: Why is_admin_of_role() use ROLERECURSE_MEMBERS rather than ROLERECURSE_PRIVS?
|
| Список | pgsql-hackers |
Hi,
According to the comment in check_role_grantor():
/*
* Otherwise, the grantor must either have ADMIN OPTION on the role or
* inherit the privileges of a role which does. In the former case,
* record the grantor as the current user; in the latter, pick one of
* the roles that is "most directly" inherited by the current role
* (i.e. fewest "hops").
*
* (We shouldn't fail to find a best grantor, because we've already
* established that the current user has permission to perform the
* operation.)
*/
grantorId = select_best_admin(currentUserId, roleid);
if (!OidIsValid(grantorId))
elog(ERROR, "no possible grantors");
But the "no possible grantors" error can happen in my test case.
The main reason is that is_admin_of_role() and select_best_admin() use different role recurse methods.
I think they should keep consistent, maybe both use ROLERECURSE_PRIVS? Thoughts?
--
Regards,
ChangAo Chen
В списке pgsql-hackers по дате отправления: