File IO about pllua HOT 5 CLOSED

If you're only using a superuser account, then just use LANGUAGE plluau in place of LANGUAGE pllua and all the io.* functions are accessible anyway. No need to mess with the config.

from pllua.

The module provides both a "trusted" language (pllua) and an "untrusted" language (plluau).

The untrusted language provides full access to the system (both the standard Lua file i/o functions and the ability to load C modules for more functionality), but functions in it can only be created by database superusers, who must assume responsibility for the safety of what they do with it. Remember that the code will be running as part of the database server, with all its privileges, so untrusted-language functions are easily able to damage or destroy the database or leak sensitive information.

The trusted language runs functions in a sandbox, and therefore no file access is allowed except via SQL statements. However, the superuser has the option of adding additional modules to the sandbox, at their own risk; see the pllua.trusted section of the docs and the on_init and on_trusted_init configuration options (under "PostgreSQL Environment" in the docs).

from pllua.

Ah, perfect. So to enable io functions e.g. the su could pass that into the init of pllua, if I understand correctly. Thanks!

from pllua.

Do NOT expose io.* to pllua that way, it's equivalent to tearing up the entire security model of the server and allowing any user to do anything they please.

The simplest way to allow limited file reading is to create functions using LANGUAGE plluau that read only specific files, and then call those via SQL in the usual way.

I can't stress too strongly that misuse of the pllua.trusted functions can lead to crashes, data loss, or security breaches.

from pllua.

I am fully aware of this. This is exactly what I want. My application is using a Postgres instance as a quasi-embedded database, with only a super-user account and no other users or user data (or roles, or restrictions). The database is not exposed or otherwise accessible outside of the application (container). So yes, I heavily agree with your warning, but this is a special case.

from pllua.