Message-ID: <4EDA6C0E.6090909@fuzzy.cz>
Date: Sat, 03 Dec 2011 19:35:58 +0100
From: Tomas Vondra <tv@fuzzy.cz>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: pgsql-hackers@postgresql.org
Subject: Re: why local_preload_libraries does require a separate
 directory ?
References: <4EDA38AE.5030003@fuzzy.cz> <17337.1322934799@sss.pgh.pa.us>
In-Reply-To: <17337.1322934799@sss.pgh.pa.us>
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: 7bit

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