Re: Restrict ALTER FUNCTION CALLED ON NULL INPUT (was Re: Not quite a security hole: CREATE LANGUAGE for non-superusers)
От | Tom Lane |
---|---|
Тема | Re: Restrict ALTER FUNCTION CALLED ON NULL INPUT (was Re: Not quite a security hole: CREATE LANGUAGE for non-superusers) |
Дата | |
Msg-id | 22776.1339532088@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Restrict ALTER FUNCTION CALLED ON NULL INPUT (was Re: Not quite a security hole: CREATE LANGUAGE for non-superusers) ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
Ответы |
Re: Restrict ALTER FUNCTION CALLED ON NULL INPUT
(was Re: Not quite a security hole: CREATE LANGUAGE for
non-superusers)
Re: Restrict ALTER FUNCTION CALLED ON NULL INPUT (was Re: Not quite a security hole: CREATE LANGUAGE for non-superusers) |
Список | pgsql-hackers |
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes: > Tom Lane <tgl@sss.pgh.pa.us> wrote: >> A less bizarre and considerably more future-proof restriction, >> IMO, would simply refuse any attempt to give ownership of a C >> function to a non-superuser. > We have C replication trigger functions where this would be a bad > thing. They can't work properly as SECURITY INVOKER, and I see it > as a big step backwards in security to make the only other option > SECURITY DEFINER with a superuser as the owner. Could you provide more details about that? If nothing else, this could be handled with a non-C wrapper function, but I'm not clear on the generality of the use-case. > 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. 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. regards, tom lane
В списке pgsql-hackers по дате отправления: