On Thu, Aug 25, 2022 at 3:03 PM Joe Conway <mail@joeconway.com> wrote:
> Nice analysis, and surprising (to me)
Thanks.
> > I argue that #3 is a clear bug. robert can't select from stuff's
> > tables or change privileges on stuff's objects, so why can he change
> > stuff's default privileges? is_member_of_role() has a note that it is
> > not to be used for privilege checking, and this seems like it's pretty
> > clearly a privilege check.
>
> +1 this feels very wrong to me
Cool. I'll prepare a patch for that, unless someone else beats me to it.
I really hate back-patching this kind of change but it's possible that
it's the right thing to do. There's no real security exposure because
the member could always SET ROLE and then do the exact same thing, so
back-patching feels to me like it has a significantly higher chance of
turning happy users into unhappy ones than the reverse. On the other
hand, it's pretty hard to defend the current behavior once you stop to
think about it, so perhaps it should be back-patched on those grounds.
On the third hand, the fact that this has gone undiscovered for a
decade makes you wonder whether we've really had clear enough ideas
about this to justify calling it a bug rather than, say, an elevation
of our thinking on this topic.
> I'm not sure about these last two. Does it matter that object creation
> is being logged, maybe for auditing purposes, under a different user
> than the owner of the object?
I'd be inclined to say that it doesn't matter, because the grant could
have just as well been inheritable, or the action could have been
performed by a superuser. Also, as a rule of thumb, I don't think we
should choose to prohibit things on the grounds that some auditing
regime might not be able to understand what happened. If that's an
issue, we should address it by making the logging better, or including
better logging hooks, or what have you. I think that the focus should
be on the permissions model: what is the "right thing" from a security
standpoint?
--
Robert Haas
EDB: http://www.enterprisedb.com
