Thread: Can we still trust plperl?
Last night my attention was drawn to this: <http://search.cpan.org/~timb/PostgreSQL-PLPerl-Injector-1.002/lib/PostgreSQL/PLPerl/Injector.pm> I'm wondering if we can reasonably continue to support plperl as a trusted language, or at least redefine what "trusted" actually means. Does it mean "can't do untrusted operations" or does it mean "can't do untrusted operations unless the DBA and/or possibly the user decide to subvert the mechanism"? To me, the latter doesn't sound much like it's worth having. Is it? There are a few places where plperl has an advantage over plpgsql, e.g. code that uses lots of regexes and use of variable to access records dynamically, so losing it might be a bit of a pain. Of course, there would still be plperlu, with the downside that the functions have to be installed by a superuser. One of my PGExperts colleagues told me his reaction was "Well, I might just as well use plperlu", and that pretty well sums up my reaction. Of course, another thing is that it might spur either building of some of the missing stuff into plpgsql, or addition of another language that is both safe and which supports them, like say PL/JavaScript. Thoughts? cheers andrew
On Thu, Mar 11, 2010 at 09:31:46AM -0500, Andrew Dunstan wrote: > > Last night my attention was drawn to this: > > <http://search.cpan.org/~timb/PostgreSQL-PLPerl-Injector-1.002/lib/PostgreSQL/PLPerl/Injector.pm> > > I'm wondering if we can reasonably continue to support plperl as a trusted > language, or at least redefine what "trusted" actually means. Does it mean > "can't do untrusted operations" or does it mean "can't do untrusted > operations unless the DBA and/or possibly the user decide to subvert the > mechanism"? To me, the latter doesn't sound much like it's worth having. Is > it? > > There are a few places where plperl has an advantage over plpgsql, e.g. > code that uses lots of regexes and use of variable to access records > dynamically, so losing it might be a bit of a pain. Of course, there would > still be plperlu, with the downside that the functions have to be installed > by a superuser. One of my PGExperts colleagues told me his reaction was > "Well, I might just as well use plperlu", and that pretty well sums up my > reaction. > > Of course, another thing is that it might spur either building of some of > the missing stuff into plpgsql, or addition of another language that is > both safe and which supports them, like say PL/JavaScript. > > Thoughts? > > cheers > > andrew > The DBA can do what ever he wants to do to subvert the system up to installing hacked versions of any other "trusted" language so I do not see much of a distinction. We already provide many other foot-guns that may be used by the DBA. pl/perl is very useful as a trusted language but I am certainly for fleshing out the features in other pl-s. Regards, Ken
Andrew Dunstan <andrew@dunslane.net> wrote:
> I'm wondering if we can reasonably continue to support plperl as
> a trusted language
> would still be plperlu, with the downside that the functions have
> to be installed by a superuser. One of my PGExperts colleagues
> told me his reaction was "Well, I might just as well use plperlu",
> and that pretty well sums up my reaction.
Well, I can see where running plperl with this module would be no
more safe than running plperlu, so I don't really understand the
purpose of the module; however, to install this module you need to:
| Set the PERL5OPT before starting postgres, to something like this:
| PERL5OPT='-e "require q{plperlinit.pl}"'
| and create a plperlinit.pl file in the same directory as your
| postgres.conf file.
| In the plperlinit.pl file write the code to load this module, plus
| any others you want to load and share subroutines from.
I don't see where plperl is unsafe unless you do those things. A
user who can do those things can likely subvert your database in
other ways, no?
-Kevin
Andrew Dunstan <andrew@dunslane.net> writes: > Last night my attention was drawn to this: > <http://search.cpan.org/~timb/PostgreSQL-PLPerl-Injector-1.002/lib/PostgreSQL/PLPerl/Injector.pm> > I'm wondering if we can reasonably continue to support plperl as a > trusted language, or at least redefine what "trusted" actually means. > Does it mean "can't do untrusted operations" or does it mean "can't do > untrusted operations unless the DBA and/or possibly the user decide to > subvert the mechanism"? To me, the latter doesn't sound much like it's > worth having. Is it? 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. 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. regards, tom lane
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