From: | "Ted Byers" <r(dot)ted(dot)byers(at)rogers(dot)com> |
---|---|
To: | "Bill Moran" <wmoran(at)potentialtech(dot)com> |
Cc: | "Postgres general mailing list" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: security permissions for functions |
Date: | 2007-03-09 05:18:47 |
Message-ID: | 0a5501c7620a$6a858a00$6401a8c0@RnDworkstation |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
>
> 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?
Ted
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-03-09 05:35:43 | Re: OT: Canadian Tax Database |
Previous Message | Tom Lane | 2007-03-09 04:30:34 | Re: Weird behaviour on a join with multiple keys |