Re: extension_control_path

On Thu, Feb 6, 2014 at 5:49 PM, David E. Wheeler <david(at)justatheory(dot)com> wrote:
> On Feb 6, 2014, at 6:51 AM, Greg Stark <stark(at)mit(dot)edu> wrote:
>
>> Homebrew sounds kind of confused. Having a non-root user have access
>> to make global system changes sounds like privilege escalation
>> vulnerability by design.
>
> Well, the point is that it *doesn't* make global system changes. I got an error on OS X Server with my original formula, because there was no permission to install in $PGROOT/share/extensions.

Installing into /usr/local is a global system change. Only root should
be able to do that and any user that can do that can easily acquire
root privileges.

>> 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.
>
> Right. And you can also add additional paths for those applications to search.

Well, users can do whatever they want at run-time but there are
blessed paths that are the correct place to install things that these
systems are configured to search automatically. My point was just that
there are generally two such blessed paths, one for the distribution
and one for the local sysadmin.

What you do not want is to have a different path for each piece of
software. That way lies the
/usr/local/kde/bin:/usr/local/gnome/bin:/usr/local/myfavouritehack/bin:...
madness. You can do this with Python or Perl but they won't do it
automatically and everyone who does this with environment variables or
command line flags eventually realizes what a mess it is. (Except Java
programmers)

--
greg