Robert Haas <robertmh...@gmail.com> writes: > On Tue, Jan 10, 2023 at 9:40 PM Tom Lane <t...@sss.pgh.pa.us> wrote: >> The scenario I'm worried about could be closed, mostly, if we were willing >> to invent an intermediate GUC privilege level "can be set interactively >> but only by CREATEROLE holders" ("PGC_CRSET"?).
> Of course, if it's possible for a non-CREATEROLE user to set the value > that a CREATEROLE user experiences, that'd be more of a problem -- That's exactly the case I'm worried about, and it's completely reachable if a CREATEROLE user makes a SECURITY DEFINER function that executes an affected GRANT and is callable by an unprivileged user. Now, that probably isn't terribly likely, and it's unclear that there'd be any serious security consequence even if the GRANT did do something different than the author of the SECURITY DEFINER function was expecting. Nonetheless, I'm feeling itchy about this chain of assumptions. > To answer your question directly, though, I don't know of any other > setting where that would be a useful level. Yeah, I didn't think of one either. Also, even if we invented PGC_CRSET, it can't stop one CREATEROLE user from attacking another one, assuming that there is some interesting attack that can be constructed here. I think the whole point of your recent patches is to not assume that CREATEROLE users are mutually trusting, so that's bad. Bottom line is that a GUC doesn't feel like the right mechanism to use. What do you think about inventing a role property, or a grantable role that controls this behavior? regards, tom lane