Re: Blocking execution of SECURITY INVOKER - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: Blocking execution of SECURITY INVOKER
Date
Msg-id 75df9bd9e09b631d66c8a07583ccfe91da359337.camel@j-davis.com
Whole thread Raw
In response to Re: Blocking execution of SECURITY INVOKER  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Thu, 2023-01-12 at 19:38 -0800, Andres Freund wrote:
> I.e. the default arguments where evaluated with the invoker's
> permissions, not
> the definer's, despite being controlled by the less privileged user.

This is a very interesting case. It also involves tricking the
superuser into executing their own function with the attacker's inputs.
That part is the same as the other case. What's intriguing here is that
it shows the function can be SECURITY INVOKER, and that really means it
could be any builtin function as long as the types work out.

For example:
=> create function trick(l pg_lsn = pg_switch_wal()) returns int
language plpgsql security definer as $$ begin return 42; end; $$;

If the superuser executes that, even though it's a SECURITY DEFINER
function owned by an unprivileged user, it will still call
pg_switch_wal().


--
Jeff Davis
PostgreSQL Contributor Team - AWS





pgsql-hackers by date:

Previous
From: Jelte Fennema
Date:
Subject: Re: [EXTERNAL] Re: [PATCH] Support using "all" for the db user in pg_ident.conf
Next
From: "Drouvot, Bertrand"
Date:
Subject: Re: Minimal logical decoding on standbys