Re: Can we still trust plperl?

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: Can we still trust plperl?
Дата
Msg-id 4B9911EA.2030005@dunslane.net
обсуждение исходный текст
Ответ на Re: Can we still trust plperl?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers

Tom Lane wrote:
> AFAICS the DBA has to participate in setting up that module, so it's
> no different from any other PL language.  You can insert stuff into the
> trusted interpreter in pltcl too.  It's on the DBA's head to not insert
> stuff that's insecure --- so what?  To my mind it's a feature not a
> bug that this is possible.  It's just like the on_init work that you've
> been doing; it's about letting the DBA have control over what users of
> the trusted language can get at.
>   

Fair enough, but I think we need to be clearer in the docs about what 
"trusted" actually means.

The docs say:
   TRUSTED specifies that the language is safe, that is, it does not   offer an unprivileged user any functionality to
bypassaccess   restrictions.
 

Perhaps we need to add some words to that to indicate that the DBA can 
inject extra functionality into some trusted PLs, which might or might 
not be able to access system resources.

> What bothers me more is the fact that genuine holes are beginning to
> show up in Safe.  I wonder if we aren't seeing the first stages of what
> happened to trusted plpython.  Building a secure sandbox feature into
> a language that wasn't designed for it is hard.  However, I'm not going
> to panic until there's reason for panic, and this doesn't look like a
> reason.
>
>             
>   

Yes, Tim was saying something about how Safe was a failed experiment to 
me the other day. I suspect we might be fairly close to having to do 
something radical about that.

cheers

andrew


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: tsearch profiling - czech environment - take 55MB
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: tsearch profiling - czech environment - take 55MB