* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> > It's not too hard
> > to come up with other use cases where you want to grant one class of
> > users rights to do something only through a certain function, not
> > directly.
>
> Generally I'd imagine that that has something to do with permission
> to call the function, not with who owns it.
What I believe Kevin is getting at here is this:
There's no way to say "run this function as user X" except by making it
SECURITY DEFINER and owned by the user you want the function to run as.
I believe everyone agrees that only a superuser should be allowed
CHANGE a C-language function. Unfortunately, being the 'OWNER' conveys
more than just the ability to change the function.
If we had an independent way to have the function run as a specific
user, where that user DIDN'T own the function, I think Kevin's use case
would be satisfied.
I'm not sure if it's be reasonable for a C-language function to just go
ahead and decide to change the user it's running as in the database..
I have to admit that I don't think I've ever tried to do that.
> Basically, if we go down the road Noah is proposing, I foresee a steady
> stream of security bugs and ensuing random restrictions on what function
> owners can do. I do not like that future.
I agree that we don't want to have to police what a function owner can
do to a function, and therefore untrusted language functions should only
be owned by superusers, but I feel that means we need to look at what
function ownership currently implies and allows and consider if those
operations should be broken out and made independently grantable. When
it comes to 'SECURITY DEFINER' and it's relationship to 'OWNER', I think
we have to provide some kind of solution that doesn't require those
functions to be run as superuser simply because the function has to be
owned by a superuser.
Thanks,
Stephen
