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

Re: SECURITY DEFINER not being propagated...

From: Sean Chittenden <sean(at)chittenden(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: SECURITY DEFINER not being propagated...
Date: 2004-04-29 07:38:28
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
>> Without any rationale as to why CREATE TEMP TABLEs checks the session
>> user in the archives, could we open this up for discussion again?
> Well, let me put it this way: if you want to change the behavior you're
> going to have to work much harder than just reverting the prior patch.
> IIRC the fundamental reason the code works that way is that
> InitTempTableNamespace is done only once per session.  If it checks
> against current_user rather than session_user then (a) the results will
> be inconsistent, and (b) you create a different sort of security hole,
> which is that if a setuid function is the first to try to create a temp
> table in a particular session, then not-so-privileged functions will
> still be able to create temp tables later in the session.

Hrm, I didn't realize that: points taken.  Since temp schemas are 
always owned by the superuser, why aren't the ACL checks done when the 
temp relation is created as opposed to when the schema is created?  I 
see what you're saying about things currently needing to use 
GetSessionuserId() instead of GetUserId(), but if a check for istemp is 
pushed down into DefineRelation(), then (from what I can tell) 
GetUserId() can be used in InitTempTableNamespace().  Object owners can 
only delete their objects, the temp schema can't be deleted as is 
because its owner is the superuser.

I think the attached patch addresses both of your concerns.  Things are 
consistent in that SECURITY DEFINER/TEMP TABLEs will now work as 
expected.  The security hole isn't an issue because security checks are 
applied both in InitTempTableNamespace() and DefineRelation().

>> At the moment, this behavior cripples the usefulness
>> of having a TEMP table be used as a trusted cache for data.
> What exactly do you think makes a temp table suitable as a trusted
> cache?  Or more suitable than non-temp tables?

Revoke all privs on temp tables except from the DBA, then setup 
functions to use the temp table as a way of maintaining state 
information across transactions (within the same session).  It's a hack 
to get around the lack of server side variables.  In many ways, 
actually, it works out better because I can wrap functions or 
PostgreSQL's permissions around the temp relations and get exactly the 
access that I need... far more fine grained than anything I could do 
with a GUC or some other server side MIB/variable implementation.

> I don't really believe in the notion of restricting temp table creation
> to setuid functions.  AFAICS the only reason for forbidding temp table
> creation is to prevent a session from using any on-disk resources, and
> that hardly works if it can still do so via calling setuid functions.

It can't populate or read data out of the temp relation though, which 
is ideal for my situation.


Attachment: patch.txt
Description: text/plain (1.7 KB)

In response to


pgsql-patches by date

Next:From: Manfred KoizarDate: 2004-04-29 16:42:31
Subject: Re: Basic subtransaction facility
Previous:From: Bruce MomjianDate: 2004-04-29 04:49:57
Subject: Re: FW: Timezone library

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