Re: allow building trusted languages without the untrusted versions

On Tue, May 24, 2022 at 09:19:40PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > I always thought if pg_proc is able to call an arbitrary function in an
> > arbitrary library, it could access to the file system, and if that is
> > true, locking the super-user from file system access seems impossible
> > and unwise to try because it would give a false sense of security.
>
> That was the situation when we had v0 function call semantics. ISTM
> we are at least a lot closer now to being able to say it's locked down:
> "internal" functions can only reach things that are in the fmgrtab
> table, and "C" functions can only reach things that have associated
> PG_FUNCTION_INFO_V1 symbols. Plus we won't load shared libraries
> that don't have PG_MODULE_MAGIC blocks. Maybe there's still a way
> around all that, but it's sure a lot less obvious than it once was,
> and there are probably things we could do to make it even harder.

Okay, good to know.

> I think would-be hackers are now reduced to doing what Robert
> suggested, which is trying to find a way to subvert a validly
> SQL-callable function by passing it bogus arguments. Maybe there's
> a way to gain filesystem access by doing that, but it's not going
> to be easy if the function is not one that intended to allow such
> operations.

Yes, I think if we can say we are safe in standard superuser-changeable
things like modifying the system tables, we might have a chance. Are
settings like archive_command safe?

--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com

Indecision is a decision. Inaction is an action. Mark Batterson