From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Andreas Karlsson <andreas(at)proxel(dot)se>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: postgres_fdw super user checks |
Date: | 2017-10-13 01:21:13 |
Message-ID: | 20171013012113.GT4628@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert, all,
* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> On Thu, Oct 5, 2017 at 1:02 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2017-10-13 01:47:25 | Re: Discussion on missing optimizations |
Previous Message | Robert Haas | 2017-10-13 00:55:14 | Re: Pluggable storage |