In response to "Ted Byers" <r.ted.byers@rogers.com>:
> >
> > Functions are controlled by the same ACL mechanism that tables and
> > everything
> > else follows. Thus you have the idea of "user id X may do Y with object
> > Z"
> > i.e. "user "barbara" may "execute" function "somefunction()".
> >
> > But there's no real way to alter those permissions outside of changing the
> > user ID context.
>
> So, I should be able to have "user "barbara" "execute" function
> "somefunction()", but, though barbara must not have access of object alpha
> lets say for data security reasons (and user sarah does), I could have
> function somefunction invoke another function that stores information about
> barbara's action to object alpha by changing user context temporarily and
> without barbara's knowledge; basically saying within function
> "somefunction()" something like "execute function 'someotherfunction()'
> impersonating sarah and stop impersonating sarah once someotherfunction
> returns. Much like the way I can log in to Windows or Linux as one user and
> temporarily impersonate another while executing a particular program or
> administrative function (e,g, log into Linux as a mere mortal, start a bash
> shell providing credentials for an admin account, do my admin type stuff and
> then close the shell).
>
> Or have I misunderstood you here WRT user ID context?
No, you're on track. Have a look at the docs for CREATE FUNCION:
http://www.postgresql.org/docs/8.1/static/sql-createfunction.html
Specifically the section on SECURITY INVOKER and SECURITY DEFINER.
SECURITY DEFINER gives you the equivalent of "setuid" capability
--
Bill Moran
http://www.potentialtech.com