Re: Where to load modules from?

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Where to load modules from?
Date: 2013-09-20 12:21:47
Message-ID: CA+Tgmob5QAFf9ji2XQtc2aEO7i4_NUMZWWDA+WHQQrzos4UT0A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Sep 20, 2013 at 8:10 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> On 2013-09-20 08:06:56 -0400, Robert Haas wrote:
>> On Thu, Sep 19, 2013 at 5:54 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
>> > Because I want to specify multiple paths. E.g. one with modules for a
>> > specific postgres version, one for the cluster and one for my
>> > development directory.
>> > Now we could recursively search a directory that contains symlinks to
>> > directories, but that seems ugly.
>
>> I see. My main hesitation is around security. I feel somehow that
>> changing a GUC to trojan the system would be easier for a remote user
>> to accomplish than having to replace a directory with a symlink.
>
> If they can change a PGC_POSTMASTER GUC, they already can easily enough
> do:
> shared_preload_libraries='/path/to/my/bad/so.so'
>
> that's already allowed.

OK. Well, in that case, it seems we wouldn't be opening any new doors.

So... our usual comma-separated GUC syntax? Empty means no extra
places to search.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2013-09-20 12:23:23 Re: Minor inheritance/check bug: Inconsistent behavior
Previous Message Andres Freund 2013-09-20 12:10:38 Re: Where to load modules from?