krzf83@xxxxxxxxx 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. -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
