Skip site navigation (1) Skip section navigation (2)

Re: Re-enabling SET ROLE in security definer functions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Turner, Ian" <Ian(dot)Turner(at)deshaw(dot)com>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Gurjeet Singh <singh(dot)gurjeet(at)gmail(dot)com>, PGSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, George Williams <george(dot)williams(at)enterprisedb(dot)com>
Subject: Re: Re-enabling SET ROLE in security definer functions
Date: 2009-12-31 20:50:59
Message-ID: 29900.1262292659@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
"Turner, Ian" <Ian(dot)Turner(at)deshaw(dot)com> writes:
>> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
>> Really?  What can it contain, and how are you enforcing that?

> Anything except a function call. We look for non-keyword identifier
> followed by open parenthesis, which is probably excessively
> restrictive.

I'm afraid this is security by wishful thinking.  Operators and casts,
to name two obvious examples, can invoke user-defined code.  Postgres
is sufficiently extensible that preventing any execution of non-core
code is nearly impossible, at least not without limiting things to
the point of uselessness.

>> Even more
>> to the point, if you have managed to restrict it to the point where
>> there's no possibility of someone executing a SET ROLE, why do you need
>> any permissions switch at all?
>> That's isomorphic to claiming that it
>> won't execute any SQL command at all, in which case you needn't worry about
>> changing permissions.

> Not sure what you mean here, can you elaborate?

If you had a mechanism that ensured that the untrusted user couldn't
execute SET ROLE (which you don't), they couldn't execute anything else
either, and therefore the question of what permissions they're running
with isn't really important.

I agree that you have a problem to solve, but defining the problem as
"please can we have SET ROLE back" is not going to lead you to a secure
solution.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Turner, IanDate: 2009-12-31 20:52:16
Subject: Re: Re-enabling SET ROLE in security definer functions
Previous:From: Turner, IanDate: 2009-12-31 20:34:28
Subject: Re: Re-enabling SET ROLE in security definer functions

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group