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

Re: Functions as a Security Layer

From: Benjamin Stookey <jamstooks(at)yahoo(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: Functions as a Security Layer
Date: 2006-01-09 03:43:24
Message-ID: 20060109034324.86964.qmail@web35013.mail.mud.yahoo.com (view raw)
Functions, with some databases, are used as security
layers so that a user that wouldn't otherwise have
read/write privileges on a table can perform some sort
of controlled update.

I've written a function to serve as a type of counter
to update a table called "users". This function takes
one (relevant) parameter: userID. This then updates
the counter with that user's id. However, I am getting
a permissions error because the users who run the
function don't have write access to the counter table.

My question is, can I somehow give permissions to the
function, but not to the user to protect the counter
table from being modified in any ways I don't want?

Thanks,
-Ben


		
__________________________________________ 
Yahoo! DSL – Something to write home about. 
Just $16.99/mo. or less. 
dsl.yahoo.com 


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Benjamin Stookey <jamstooks(at)yahoo(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Functions as a Security Layer
Date: 2006-01-09 03:50:46
Message-ID: 25323.1136778646@sss.pgh.pa.us (view raw)
Benjamin Stookey <jamstooks(at)yahoo(dot)com> writes:
> My question is, can I somehow give permissions to the
> function, but not to the user to protect the counter
> table from being modified in any ways I don't want?

Label the function SECURITY DEFINER.

			regards, tom lane

From: Shelby Cain <alyandon(at)yahoo(dot)com>
To: Benjamin Stookey <jamstooks(at)yahoo(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Functions as a Security Layer
Date: 2006-01-09 04:03:47
Message-ID: 20060109040347.55385.qmail@web50111.mail.yahoo.com (view raw)

--- Benjamin Stookey <jamstooks(at)yahoo(dot)com> wrote:

> Functions, with some databases, are used as security
> layers so that a user that wouldn't otherwise have
> read/write privileges on a table can perform some sort
> of controlled update.
> 
> I've written a function to serve as a type of counter
> to update a table called "users". This function takes
> one (relevant) parameter: userID. This then updates
> the counter with that user's id. However, I am getting
> a permissions error because the users who run the
> function don't have write access to the counter table.
> 
> My question is, can I somehow give permissions to the
> function, but not to the user to protect the counter
> table from being modified in any ways I don't want?
> 
> Thanks,
> -Ben
> 

http://www.postgresql.org/docs/8.1/static/sql-createfunction.html

Check out the difference between "security invoker" and "security
definer".  If the creating user has the necessary access to the
underlying objects you'll get the behavior you desire.

Shelby Cain


		
__________________________________________ 
Yahoo! DSL – Something to write home about. 
Just $16.99/mo. or less. 
dsl.yahoo.com 


From: Benjamin Stookey <jamstooks(at)yahoo(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: Functions as a Security Layer
Date: 2006-01-09 04:18:31
Message-ID: 20060109041831.42619.qmail@web35007.mail.mud.yahoo.com (view raw)
Thanks so much. That did the trick!

--- Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Benjamin Stookey <jamstooks(at)yahoo(dot)com> writes:
> > My question is, can I somehow give permissions to
> the
> > function, but not to the user to protect the
> counter
> > table from being modified in any ways I don't
> want?
> 
> Label the function SECURITY DEFINER.
> 
> 			regards, tom lane
> 
> ---------------------------(end of
> broadcast)---------------------------
> TIP 5: don't forget to increase your free space map
> settings
> 



		
__________________________________________ 
Yahoo! DSL – Something to write home about. 
Just $16.99/mo. or less. 
dsl.yahoo.com 



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