krzf83@gmail.com wrote
> test_dd=> CREATE EXTENSION plpython3u;
> ERROR: permission denied to create extension "plpython3u"
> HINT: Must be superuser to create this extension.
> test_dd=> CREATE EXTENSION plperl;
> CREATE EXTENSION
>
> Does that mean that installing plpython3u can break security model on
> shared database server? Does that mean that plperl won't break it?
> Security implications (on shared database server) of intalling
> extensions are still undocumented.
If you give a user permission to write functions using untrusted languages
it is the same as giving that user access to the O/S shell using the
postgres o/s user account.
Both pl/python and pl/perl say this though not as succinctly (which means I
may be over-simplifying things...).
For me at least you'd need to be more specific about "security model" and
what "breaking it" means...
Extensions in general and languages specifically have different security
considerations so discussing them like they are synonyms doesn't help. A
non-language extension containing C-language (untrusted) functions will open
the same general exposure to the o/s that other untrusted languages expose
but normal users cannot write custom behavior into those functions while
giving them access to untrusted languages will do so. A trusted language is
much more like pl/pgsql in that it can interact in a limited way directly
with the o/s but otherwise is restricted to using the trusted interfaces
(e.g., COPY) that PostgreSQL provides.
David J.
--
View this message in context:
http://postgresql.nabble.com/Must-be-superuser-to-create-this-extension-tp5837398p5837409.html
Sent from the PostgreSQL - admin mailing list archive at Nabble.com.
