Re: Question regarding dynamic_library_path

"Tommi Maekitalo" <t(dot)maekitalo(at)epgmbh(dot)de> wrote:
> Hi,
>
> in linux you can change LD_LIBRARY_PATH in a running process, but it does
not
> help. The library-loader initializes himself at process-startup and
changing
> LD_LIBRARY_PATH do not change the actual path, the process is using for
> dlopen.
>
That's bad. My nice suggestion just scattered into pieces :-)

But then again, perhaps not. Isn't the fact that "dynamic_library_path" can
be changed at any time by a user a serious security flaw? It enables the
user to load a module from an arbitrary place and then execute what's in
that module with postmaster priviligies. I.e. there's nothing preventing
such a user to access all data in the database using low-level C-routines
and bypass the security imposed by PostgreSQL.

IMHO, the DB-admin should be able to limit what's loaded by defining loader
constraints. Regardless of the previous discussion I would suggest the
following:

1. Prohibit use of paths containing a directory component in SQL.
2. Make dynamic_library_path a PGC_POSTMASTER variable.

This would close the security hole and give the DB Admin full control over
what a user can and cannot load.

Now, back to my original suggestion.

Using the current desing, the postmaster would still not be able to set the
LD_LIBRARY_PATH from the dynamic_library_path on Unix since all it does when
a new connection is established is a fork. So on a Unix machine with Linux
behavior the postmaster would need to parse the config file on startup,
merge dynamic_library_path with LD_LIBRARY_PATH (or whatever is applicable),
set the environment, and then do re-exec using some flag indicating
"stage2". Stage 2 would do exactly what's done today but ignore the
dynamic_library_path setting completely.

I realize that this is stretching it a little :-). The part concerning the
security-leak is important though.

Kind regards,

Thomas Hallgren