Re: extension_control_path - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: extension_control_path
Date
Msg-id 20140206153251.GD2921@tamriel.snowman.net
Whole thread Raw
In response to Re: extension_control_path  (Greg Stark <stark@mit.edu>)
Responses Re: extension_control_path  ("David E. Wheeler" <david@justatheory.com>)
List pgsql-hackers
* Greg Stark (stark@mit.edu) wrote:
> On Tue, Feb 4, 2014 at 6:07 PM, David E. Wheeler <david@justatheory.com> wrote:
> > The install failed, of course, because extensions want to install in $PGROOT/share/extensions.
>
> Homebrew sounds kind of confused. Having a non-root user have access
> to make global system changes sounds like privilege escalation
> vulnerability by design.

I've not played w/ Homebrew myself, but it's installing into /usr/local
and presumably that includes installing things into /usr/local/bin, so
the notion that installing something from Homebrew isn't already (and
intended to be) making global system changes doesn't quite line up.

The end-admin would have to modify the system-installed postgresql.conf
anyway to enable this other directory.  David wasn't suggesting that
Homebrew *should* be able to do so, he was pointing out that it *can't*,
which all makes sense imv.

> However putting that aside, it is fairly standard for software to
> provide two directories for extensions/modules/plugins/etc. One for
> distribution-built software such as /usr/share/emacs/site-lisp/ and
> another for sysadmin customizations such as
> /usr/local/share/emacs/site-lisp. The same idea as /usr/share/perl and
> /usr/local/share/perl or with Python or anything else.

Agreed.
Thanks,
    Stephen

pgsql-hackers by date:

Previous
From: "ktm@rice.edu"
Date:
Subject: Re: open and close columns in the NEW record not allowed
Next
From: Andrew Dunstan
Date:
Subject: adt Makefile, was Re: jsonb and nested hstore