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
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? |