Robert, all,
* Robert Haas (robertmhaas@gmail.com) wrote:
> On Thu, Oct 5, 2017 at 1:02 PM, Jeff Janes <jeff.janes@gmail.com> wrote:
> > I don't see a reason to block a directly-logged-in superuser from using a
> > mapping. I asked in the closed list whether the current (released)
> > behavior was a security bug, and the answer was no. And I don't know why
> > else to block superusers from doing something other than as a security bug.
> > Also it would create a backwards compatibility hazard to revoke the ability
> > now.
>
> Well, my thought was that we ought to be consistent about whose
> authorization matters. If we're using the view owner's credentials in
> general, then we also (defensibly, anyway) ought to use the view
> owner's superuser-ness to decide whether to enforce this restriction.
> Using either the view owner's superuser-ness or the session user's
> superuser-ness kind of puts you halfway in the middle. The view
> owner's rights are what matters mostly, but your own rights also
> matter a little bit around the edges. That's a little strange.
>
> I don't have violently strong opinions about this - does anyone else
> have a view?
I haven't been following this closely, but I tend to agree with you- if
we're using the view owner's privileges then that's what everything
should be based on, not whether the caller is a superuser or not.
Consider a security-definer function. Clearly, such a function should
always run as the owner of the function, even if the caller is a
superuser. Running as the caller instead of the owner of the function
when the caller is a superuser because that would allow the function to
access more clearly isn't a good idea, imv.
Yes, that means that sometimes when superusers run things they get
permission denied errors. That's always been the case, and is correct.
Thanks!
Stephen