Re: SECURITY DEFINER not being propagated...

>> This one's simple enough to reproduce (see SQL script below), but,
>> there are some comments in src/backend/catalog/namespace.c that seem
>> questionable and incorrect:
>
> The proposed patch reverts a change deliberately applied in namespace.c
> rev 1.15 (4/29/02). I think you need to go back and consult the schema
> privilege discussions that occurred just before that; I'm much too
> tired
> to do so myself right at the moment ...

I can see that it was done in rev 1.15, but I haven't seen any
discussion that suggests that it was deliberate beyond what's in the
comment... but that's lacking rationale, IMHO. The thread that I think
you're referring to begins here:

http://archives.postgresql.org/pgsql-hackers/2002-04/msg01035.php

But here's pretty much the only relevant thread:

http://archives.postgresql.org/pgsql-hackers/2002-04/msg01191.php

But it doesn't have a conclusion, synopsis, or any agreement that comes
close to, "here's why we check the perms for the session user and not
the current user." Having the permissions for CREATE TEMP TABLE check
on the session user defeats the purpose of having functions run as
SECURITY DEFINER.

Without any rationale as to why CREATE TEMP TABLEs checks the session
user in the archives, could we open this up for discussion again? To
me, it seems to fly directly in the face of a function running as
SECURITY DEFINER. At the moment, this behavior cripples the usefulness
of having a TEMP table be used as a trusted cache for data.

-sc

--
Sean Chittenden