Re: Can we still trust plperl?

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com>
Subject: Re: Can we still trust plperl?
Date: 2010-03-11 15:53:14
Message-ID: 4B9911EA.2030005@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 bypass access
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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2010-03-11 16:03:15 Re: tsearch profiling - czech environment - take 55MB
Previous Message Tom Lane 2010-03-11 15:52:40 Re: tsearch profiling - czech environment - take 55MB