Re: Restrict ALTER FUNCTION CALLED ON NULL INPUT (was Re: Not quite a security hole: CREATE LANGUAGE for non-superusers)
От | Robert Haas |
---|---|
Тема | Re: Restrict ALTER FUNCTION CALLED ON NULL INPUT (was Re: Not quite a security hole: CREATE LANGUAGE for non-superusers) |
Дата | |
Msg-id | CA+TgmoaCvZ6+wSPuudq7JA_6RCzgwg8kp7J1FryysgqGZcfMFg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Restrict ALTER FUNCTION CALLED ON NULL INPUT (was Re: Not quite a security hole: CREATE LANGUAGE for non-superusers) (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Fri, Jul 20, 2012 at 3:45 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> I don't particularly care for that solution; it seems like a kludge. >> I've kind of wondered whether we ought to have checks in all the ALTER >> routines that spit up if you try to ALTER an extension member from any >> place other than an extension upgrade script... but that still >> wouldn't prevent the extension owner from dropping the members out of >> the extension and then modifying them afterwards. I'm not sure we >> want to prevent that in general, but maybe there could be some >> locked-down mode that has that effect. > > Right, I wasn't too clear about that, but I meant that we'd have some > sort of locked-down state for an extension that would forbid fooling > with its contents. For development purposes, or for anybody that "knows > what they're doing", adding/subtracting/modifying member objects is > mighty handy. But a non-superuser who's loaded an extension that > contains C functions ought not have those privileges for it. I could see having such a mode. I'm not sure that it would eliminate people's desire to manually give away functions, though. In fact, thinking about a couple of our customers, I'm pretty sure it wouldn't.Now whether it's a good idea is another question, but... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: