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

Re: Fixing insecure security definer functions

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Fixing insecure security definer functions
Date: 2007-05-29 02:55:33
Message-ID: 20070529025533.GQ7531@tamriel.snowman.net (view raw or flat)
Thread:
Lists: pgsql-hackers
* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > It would be useful to have a function which could be passed a relative
> > (to the caller's search path) object name and would return the fully
> > qualified name of that object.  In this way, functions could be written
> > which take relative arguments from the user but *only* those explicitly
> > checked for.
> 
> Your example doesn't seem to be doing anything interesting ... am I
> misunderstanding, or did you omit the actual checking?  Also, if the
> search path is controlled by the function, what good is this ---
> wouldn't it always result in a trusted schema?

The idea was that 'pg_getfullpath()' would return the full path to an
object relative to the caller's path while in a function which has an
explicit search_path defined.  Probably more sensible is an example of
what I'm thinking the function would do:

postgres=# create schema myschema;
CREATE SCHEMA
postgres=# set search_path=myschema;
SET
postgres=# create table abc (a int);
CREATE TABLE
postgres=# select pg_getfullpath('abc');
 fullpath
----------
 myschema.abc

The 'special' bit here is that pg_getfullpath() would work relative to
the caller's search_path even inside of a function which has its 'PATH'
set.  That's really the only thing about it that makes it very
interesting.

Of course, thinking a bit farther along, this would only be useful when
building up an SQL statement as a string to then execute, but you have
to do that if you're getting a table passed in as an argument anyway
(and is exactly what I'm doing).

Hope that helps.

	Thanks,

		Stephen

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2007-05-29 03:19:26
Subject: Re: Fixing insecure security definer functions
Previous:From: Tatsuo IshiiDate: 2007-05-29 02:49:00
Subject: Re: What is the maximum encoding-conversion growth rate, anyway?

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