On Thu, Oct 14, 2021 at 1:43 PM Stephen Frost <sfrost@snowman.net> wrote:
> I'm not sure that it's really inconsistent- if you want the function to
> run as someone else, define it as SECURITY DEFINER and it will. If the
> function is defined as SECURITY INVOKER then it'll run with the
> privileges of the user invoking the function- which can be pretty handy
> if, say, the function references CURRENT_USER.
That presumes that (1) the user who owns the view also owns the
function and (2) the user who created the view and the function wants
to permit people who query the view to call the function with any
arguments, rather than only those arguments that would be passed by
querying the view. Neither of those things is necessarily true.
I am not really sure that we can get away with changing this, since it
is long-established behavior. At least, if we do, we are going to have
to warn people to watch out for backward-compatibility issues, some of
which may not be things breaking functionally but rather having a
different security profile. But, in a green field, I don't know why
it's sane to suppose that if you query a view, the things in the view
behave partly as if the user querying the view were running them, and
partly as if the user owning the view were one of them. It seems much
more logical for it to be one or the other.
--
Robert Haas
EDB: http://www.enterprisedb.com