Re: role self-revocation

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: role self-revocation
Дата
Msg-id 208419.1646677694@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: role self-revocation  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: role self-revocation  (Robert Haas <robertmhaas@gmail.com>)
Re: role self-revocation  (Mark Dilger <mark.dilger@enterprisedb.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> It appears to me that the actual behavior of having is_admin_of_role()
> return true when member == role dates to
> f9fd1764615ed5d85fab703b0ffb0c323fe7dfd5 (Tom Lane, 2005). If I'm not
> reading this code wrong, prior to that commit, it seems to me that we
> only searched the roles that were members of that role, directly or
> indirectly, and you had to have admin_option on the last hop of the
> membership chain in order to get a "true" result. But that commit,
> among other changes, made member == role a special case, but the
> comment just says /* Fast path for simple case */ which makes it
> appear that it wasn't thought to be a behavior change at all, but it
> looks to me like it was. Am I confused?

Ugh, I think you are right.  It's been a long time of course, but it sure
looks like that was copied-and-pasted without recognizing that it was
wrong in this function because of the need to check the admin_option flag.
And then in the later security discussion we didn't realize that the
problematic behavior was a flat-out thinko, so we narrowed it as much as
we could instead of just taking it out.

Does anything interesting break if you do just take it out?

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: role self-revocation
Следующее
От: Robert Haas
Дата:
Сообщение: Re: role self-revocation