Re: why local_preload_libraries does require a separate directory ? - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: why local_preload_libraries does require a separate directory ?
Date
Msg-id 4EDA6C0E.6090909@fuzzy.cz
Whole thread Raw
In response to Re: why local_preload_libraries does require a separate directory ?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: why local_preload_libraries does require a separate directory ?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 3.12.2011 18:53, Tom Lane wrote:
> Tomas Vondra <tv@fuzzy.cz> writes:
>> why the libraries loaded using local_preload_libraries need to be placed
>> in a different subdirectory than libraries loaded using
>> shared_preload_libraries?
>
> Security: it lets the DBA constrain which libraries are loadable this way.

But local_preload_libraries can be set only in postgresql.conf, right?
As this file is maintainted by the DBA, so how does this improve the
security?

The problem I'm trying to solve right now is that I do have an extension
that needs to install two .so libraries - one loaded using
shared_preload_libraries, one loaded using local_preload_libraries.

The "make install" puts both files into $libdir, so I have to copy it to
the right directory.

>> I do understand that leaving the users to load whatever libraries they
>> want is a bad idea, but when the library is loaded from postgresql.conf
>> it should be safe.
>
> We don't have a mechanism that would allow different limitations to be
> placed on a GUC variable depending on where the value came from.
> To do what you're proposing would require restricting
> local_preload_libraries to be superuser-only, which would be a net
> decrease in functionality.

Now I'm really confused. AFAIK local_preload_libraries can be set only
from postgresql.conf, not by a user. So the check could be quite simple
- is the backend already started? No: don't check the path. Yes: check
that the path starts with '$libdir/plugin'.

Tomas


pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Command Triggers
Next
From: Tom Lane
Date:
Subject: Re: Inlining comparators as a performance optimisation