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

Re: SECURITY DEFINER not being propagated...

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Sean Chittenden <sean(at)chittenden(dot)org>
Cc: PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: SECURITY DEFINER not being propagated...
Date: 2004-04-29 04:03:40
Message-ID: 5523.1083211420@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-patches
Sean Chittenden <sean(at)chittenden(dot)org> writes:
> 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.

> 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?

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.

			regards, tom lane

In response to

Responses

pgsql-patches by date

Next:From: Bruce MomjianDate: 2004-04-29 04:26:01
Subject: Re: Basic subtransaction facility
Previous:From: Sean ChittendenDate: 2004-04-28 21:46:58
Subject: Re: SECURITY DEFINER not being propagated...

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