Re: role self-revocation - Mailing list pgsql-hackers

From Tom Lane
Subject Re: role self-revocation
Date
Msg-id 208419.1646677694@sss.pgh.pa.us
Whole thread Raw
In response to Re: role self-revocation  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: role self-revocation
Re: role self-revocation
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: role self-revocation
Next
From: Robert Haas
Date:
Subject: Re: role self-revocation