Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH]
От | Andrew Dunstan |
---|---|
Тема | Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH] |
Дата | |
Msg-id | 4B6A09B7.2000108@dunslane.net обсуждение исходный текст |
Ответ на | Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH] (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Add on_trusted_init and on_untrusted_init to plperl
UPDATED [PATCH]
Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH] |
Список | pgsql-hackers |
Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: > >> %_SHARED has been around for several years now, and if there are genuine >> security concerns about it ISTM they would apply today, regardless of >> these patches. >> > > Yes. I am not at all happy about inserting nonstandard permissions > checks into GUC assign hooks --- they are not really meant for that > and I think there could be unexpected consequences. Without a serious > demonstration of a real problem that didn't exist before, I'm not in > favor of it. > Agreed. > I think a more reasonable answer is just to add a documentation note > pointing out that %_SHARED should be considered insecure in a multi-user > database. > Seems fair. > What I was actually wondering about, however, is the extent to which > the semantics of Perl code could be changed from an on_init hook --- > is there any equivalent of changing search_path or otherwise creating > trojan-horse code that might be executed unexpectedly? And if so is > there any point in trying to guard against it? AIUI there isn't > anything that can be done in on_init that couldn't be done in somebody > else's function anyhow. > > > The user won't be able to do anything in the on_init hook that they could not do from a plperl function anyway. In fact less, as SPI is not being made available. Plperl functions can't load arbitrary modules at all, and can't modify perl's equivalent of search_path. So I think the plain answer to your wonder ins "no, it can't happen." There has been discussion in the past about allowing plperl functions access to certain modules. There is some sense in doing this, as it would help to avoid having to write plperlu for perfectly innocuous operations. But the list of allowed modules would have to be carefully controlled in something like a SIGHUP setting. We're certainly not going to allow such decisions to be made by anyone but the DBA. cheers andrew
В списке pgsql-hackers по дате отправления: