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: Gurjeet Singh <singh(dot)gurjeet(at)gmail(dot)com>
Cc: PGSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, "Turner, Ian" <Ian(dot)Turner(at)deshaw(dot)com>, George Williams <george(dot)williams(at)enterprisedb(dot)com>
Subject: Re: Re-enabling SET ROLE in security definer functions
Date: 2009-12-31 17:06:24
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Gurjeet Singh <singh(dot)gurjeet(at)gmail(dot)com> writes:
>     We are seeking to enable SET ROLE in security-definer functions, since @
> D.E Shaw there are scripts from the past that used this feature, and I think
> you'd also agree that SET ROLE is security definer functions has it's uses.

Actually, I don't find that to be a given.  Exactly what use-cases have
you got that aren't solved as well or better by calling a SECURITY DEFINER
function owned by the target role?

>     As the code stands right now, I see that the only concern against
> enabling SET ROLE in SecDef functions is that, that when the local-user-id
> change context is exited, the GUC might be left out of sync.

This statement represents a complete lack of understanding of the actual
security problem.  The actual security problem is that SET ROLE allows
you to become any role that the *session* user is allowed to become.
The reason for locking it down in security-restricted contexts is that
we don't want that to happen: we need to confine the available
privileges to only those that, say, the owner of the table being
vacuumed would have.

While it's possible that we could design some mechanism that would
enforce this properly, I fear that it would be tricky and a likely
source of future new security problems.  In any case the net result
would be that SET ROLE would behave differently from spec, so it would
still be non-standard-compliant, just differently from before.  So IMHO
you really need to offer a convincing reason why we should even try to
solve this, as opposed to telling people to use security definer

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Kevin GrittnerDate: 2009-12-31 17:10:02
Subject: Re: Serializable Isolation without blocking
Previous:From: Robert HaasDate: 2009-12-31 16:53:12
Subject: Re: point_ops for GiST

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