Re: allow building trusted languages without the untrusted versions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: allow building trusted languages without the untrusted versions
Date
Msg-id 1772516.1653441580@sss.pgh.pa.us
Whole thread Raw
In response to Re: allow building trusted languages without the untrusted versions  (Bruce Momjian <bruce@momjian.us>)
Responses Re: allow building trusted languages without the untrusted versions
List pgsql-hackers
Bruce Momjian <bruce@momjian.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.

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.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: PG15 beta1 fix pg_stats_ext/pg_stats_ext_exprs view manual
Next
From: Tom Lane
Date:
Subject: Re: Limiting memory allocation