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
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 |