According to the docs:

PL/Python is only available as an "untrusted" language, meaning it does not offer any way of restricting what users can do in it and is therefore named plpythonu. A trusted variant plpython might become available in the future if a secure execution mechanism is developed in Python.

Why exactly is it difficult to develop a secure execution mechanism for Python but not for other languages such as Perl?

1 Answer 1


It's to do with Python's object model - there's always a way to get a reference to objects that could be unsafe. See the rexec module documentation and the restricted execution chapter of the docs for some info on the problems, as well as:

The limitations aren't anything to do with PostgreSQL its self, they're inherent to the CPython interpreter implementation or possibly even the Python language its self.

Some other languages have checked runtimes, like Perl, Java, JavaScript and Lua. Most of them have faced a series of security issues as such confined execution environments are very hard to protect against all possible jailbreak exploits.

There's really nothing stopping PostgreSQL from adding a semitrusted Python interpreter, since rexec is "good enough" for many purposes. PostgreSQL doesn't tend to be keen on only-mostly-kinda-good-enough-maybe though. It would probably only be accepted if marked superuser-only, but you could always then grant access to it for specific users. It'd be better than untrusted Python.

Personally I think PL/V8 or similar is the future here, and would like to see it move toward being supported in core.

I've also vaguely explored the idea of a trusted Mono that can load "safe" assemblies written in C#, VB.NET, IronPython, or whatever but haven't been able to do much on that topic.

  • I have never seen this as a reason for why it is considered untrusted. By default, Java, V8, TCL, R, and other are considered untrusted. The only reason Perl is trusted is bc they ship a special trusted version of Perl with PostgreSQL postgresql.org/docs/11/plperl-trusted.html
    – TheSteve0
    Sep 11, 2019 at 3:29
  • 1
    @TheSteve0 You may not have seen it as such, but that is why it is so. PostgreSQL used to have plpythonu, and it was removed after the deprecation of the Python rexec module as inherently insecure, as linked above. I imagine maybe a plpython using PyPi might be able to deliver a restricted mode that Pg could then use. I haven't looked to see if there's much work. You are incorrect about a "special trusted version of Perl" too - it is in fact perfectly ordinary Perl, the same interpreter is used for plperl and plperlu. The difference is the runtime configuration. Sep 11, 2019 at 5:30
  • 1
    @TheSteve0 plperl configures the Perl interpreter instances differently at runtime. See plperl.c for the gorey details, specifically pp_require_safe and plperl_trusted_init. I don't know enough to have much of an opinion as to the true safety of restricted Perl execution. I would prefer to see a trusted version of Lua or to get better mindshare and adoption, a trusted JavaScript interpreter. But what we have is plperl for now. Sep 11, 2019 at 5:37
  • 1
    @TheSteve0 BTW, the Java JVM using Java or Groovy code, or the Mono VM using C# or VB.NET would seem to make a lot of sense as both runtimes have robust sandbox and security management features. Java's SecurityManager for example. But unfortunately both runtimes use heavyweight-startup, threaded , shared-everything-by-default execution models that are a poor fit for PostgreSQL's lightweight process shared-nothing-by-default fork()-without-exec model. They aren't really fork()able. So we can't use them very effectively in PostgreSQL. Sep 11, 2019 at 5:40
  • Readers here might be interested in this GitHub issue I made on the Mono project re using Mono in fork()ing runtimes: github.com/mono/mono/issues/11857 Sep 11, 2019 at 5:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.