On 2013-06-04 13:25:10 -0400, Tom Lane wrote:
> Oliver Charles <ollie@ocharles.org.uk> writes:
> > I am working with the NixOS Linux Distribution [nixos], which has a
> > fairly radical approach to package management. If you aren't familiar
> > with it, essentially all packages are installed in isolation - such that
> > packages cannot interfere with each other.
>
> Maybe you need to rethink that concept. Surely there are many other
> cases where package A extends package B and needs to be installed
> somewhere where B is expecting to look for extensions.
Yea, I have my doubt about that concept as well.
> > This is causing a bit of a problem with PostgreSQL extensions that are
> > usually installed via CREATE EXTENSION. For extensions to be used, a
> > .control file must be placed in SHAREDIR/extension, but this is not
> > possible under NixOS as once PostgreSQL is installed that directory is
> > essentially immutable.
>
> > What wolud work best for us is to allow this path to be configurable,
> > ideally through either an environment variable, command line switch, or
> > (and this is the least desirable) a postgresql.conf option.
>
> Basically, none of those are likely to get accepted because of security
> concerns. We *don't* want this path to be run-time adjustable.
But I have to say, I think this argument isn't all that convincing
either. Without superuser rights loading a control file shouldn't give
you any more permissions than plainly executing the sql script
yourself. Everything else would be a bug we need to fix.
With superuser rights there is nothing stopping the user to LOAD the
library directly or create a C function that has an arbitrary library
path hardcoded directly. With the latter you can trivially enough
replace pg internal functions that are normally executed so you effectively
have something which will get executed on every connection.
Placing restrictions on what can be done in postgresql.conf, which
already has access to shared_preload_libraries, doesn't provide
additional protection as well since we don't require specific locations
for files in s_p_l anyway.
The only argument with a good bit of merit I can see is that it could
lead to unexpected extensions being loaded if e.g. hstore isn't
installed in the normal extension directory but another extension with
the same name somewhere else. But that seems like a problem of the
system administrator that configured the additional directories.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services