On Thu, Feb 6, 2014 at 5:49 PM, David E. Wheeler <da...@justatheory.com> wrote: > On Feb 6, 2014, at 6:51 AM, Greg Stark <st...@mit.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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers