Robert, all, * Robert Haas (robertmh...@gmail.com) wrote: > On Thu, Oct 5, 2017 at 1:02 PM, Jeff Janes <jeff.ja...@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
signature.asc
Description: Digital signature