Re: allow building trusted languages without the untrusted versions

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: allow building trusted languages without the untrusted versions
Дата
Msg-id 1772516.1653441580@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: allow building trusted languages without the untrusted versions  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: allow building trusted languages without the untrusted versions  (Bruce Momjian <bruce@momjian.us>)
Список 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 по дате отправления:

Предыдущее
От: Justin Pryzby
Дата:
Сообщение: Re: PG15 beta1 fix pg_stats_ext/pg_stats_ext_exprs view manual
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Limiting memory allocation