Re: RFC: Additional Directory for Extensions

Поиск
Список
Период
Сортировка
От David E. Wheeler
Тема Re: RFC: Additional Directory for Extensions
Дата
Msg-id BCEAAEE5-44A3-4B9A-A39B-87BE5B287003@justatheory.com
обсуждение исходный текст
Ответ на Re: RFC: Additional Directory for Extensions  ("David E. Wheeler" <david@justatheory.com>)
Ответы Re: RFC: Additional Directory for Extensions  (Christoph Berg <myon@debian.org>)
Список pgsql-hackers
On Apr 3, 2024, at 8:54 AM, David E. Wheeler <david@justatheory.com> wrote:

> Yes, I like the suggestion to make it require a restart, which lets the sysadmin control it and not limited to
whateverthe person who compiled it thought would make sense. 

Here’s a revision of the Debian patch that requires a server start.

However, in studying the patch, it appears that the `extension_directory` is searched for *all* shared libraries, not
justthose being loaded for an extension. Am I reading the `expand_dynamic_library_name()` function right? 

If so, this seems like a good way for a bad actor to muck with things, by putting an exploited libpgtypes library into
theextension directory, where it would be loaded in preference to the core libpgtypes library, if they couldn’t exploit
theoriginal. 

I’m thinking it would be better to have the dynamic library lookup for extension libraries (and LOAD libraries?)
separate,so that the `extension_directory` would not be used for core libraries. 

This would also allow the lookup of extension libraries prefixed by the directory field from the control file, which
wouldenable much tidier extension installation: The control file, SQL scripts, and DSOs could all be in a single
directoryfor an extension. 

Thoughts?

Best,

David



Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jakub Wartak
Дата:
Сообщение: Re: pg_combinebackup --copy-file-range
Следующее
От: Jacob Champion
Дата:
Сообщение: Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~?