In response to "Ted Byers" <r.ted.byers@xxxxxxxxxx>: > > > > 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
