* Tom Lane (t...@sss.pgh.pa.us) wrote: > "Kevin Grittner" <kevin.gritt...@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
signature.asc
Description: Digital signature