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

Re: Re-enabling SET ROLE in security definer functions

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: "Turner, Ian" <Ian(dot)Turner(at)deshaw(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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 19:44:17
Message-ID: 4B3CFF11.1080903@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Turner, Ian wrote:
>> -----Original Message-----
>> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
>> 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?
> 
> Oh, that's easy: If you want to do the equivalent of setreuid(geteuid(), getuid()); that is, if you want to drop privileges for a particular operation. Our particular use case is that we want to evaluate an expression provided by the caller but with the caller's privileges.

Now *that's* what we should focus on. That's a reasonable use case, but
it doesn't seem like SET ROLE quite cuts it. For starters, wouldn't it
be possible for the caller's expression to call SET ROLE or RESET ROLE
to regain the privileges?

You could write a user-defined C function that does the same that
VACUUM/ANALYZE etc. do (now that we've fixed the vulnerabilities). Ie.
something like:

GetUserIdAndSecContext(&save_userid, &save_sec_context);
SetUserIdAndSecContext(<userid with less privileges>, save_sec_context |
SECURITY_RESTRICTED_OPERATION);
<call function>
/* Restore userid and security context */
SetUserIdAndSecContext(save_userid, save_sec_context);

No modifications to the server code required. Another question is, could
we provide some built-in support for dropping privileges like this?

-- 
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2009-12-31 19:53:33
Subject: Re: Re-enabling SET ROLE in security definer functions
Previous:From: Simon RiggsDate: 2009-12-31 19:25:38
Subject: Re: Thoughts on statistics for continuously advancing columns

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