Installer option? python -> .../Cellar/…/python(2|3)


(Gavan Schneider) #1

Ok I have installed python and ended up with python2 and python3. No harm in that — in fact it’s pretty much standard. And, hassle free, thank you again.

My suggestion is for ‘brew install python3’ to offer to make /usr/local/bin/python, etc point to python3, etc., rather than the current default of python2. (And I am simplifying the version numbers here.)
I am “looking to the future” and have no personal code legacy to support. So python3 is where I want to go.

Legacy issues are handled since /usr/bin/python, etc remains unchanged — the newly installed pythons in the Cellar are not going to be seen by any pre-existing system code since these processes will not have /usr/local/bin on their $PATH, or their shebang.

Of course this isn’t for everyone, hence the suggestion for an installer choice to leave the python2 family as the default vs a change making the default python3. Depending on the user’s selection the bare symlinks can then point to the desired numbered version.

Of course careful programers should continue to use python3 in the shebang and/or have a coded version trap (esp. if their code is likely to be used ‘off site’), but, for general work the day to day convenience would be nice.

Looking around on the net for discussion of ‘solutions’ it’s mostly about defining an alias (or four), or tinkering with links. Neither is attractive to me: confusing, error-prone and ongoing maintenance issues. And I don’t want to consider putting ~/…/bin at the top of my $PATH (opens serious security vulnerabilities).

Is this installer option worth considering?

BTW if I was to replace symlinks in /usr/local/bin such as: python -> ./python3 would this mess with the brew when it came to python3 updates (or would the links just get overwritten, i.e., need maintenance)? The extra level of indirection doesn’t bother me, esp. as the links would otherwise continue to point to the updated versions as they are installed.


(Mike McQuaid) #2

This is something we may consider in future but I’d advise you personally to consider creating an alias for this or adding something to your $PATH.


(Gavan Schneider) #3

Thank you, and done. Trusting this will stay out of the way and cause no harm going forward. I lost count of the symlinks as I explored the chain. :slight_smile:

Rosebud:~ gavan$ echo $PATH
/usr/local/bin/.symlfix:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:…
Rosebud:~ gavan$ ls -las /usr/local/bin/.symlfix
total 56
0 drwxr-xr-x 9 gavan admin 306 Jan 9 20:18 .
0 drwxrwxr-x 130 gavan admin 4420 Jan 9 19:50 …
8 lrwxr-xr-x 1 gavan admin 11 Jan 9 20:11 2to3 -> …/2to3-3.6
8 lrwxr-xr-x 1 gavan admin 19 Jan 9 20:10 easy_install -> …/easy_install-3.6
8 lrwxr-xr-x 1 gavan admin 10 Jan 9 20:16 idle -> …/idle3.6
8 lrwxr-xr-x 1 gavan admin 9 Jan 9 20:17 pip -> …/pip3.6
8 lrwxr-xr-x 1 gavan admin 11 Jan 9 20:18 pydoc -> …/pydoc3.6
8 lrwxr-xr-x 1 gavan admin 10 Jan 9 19:52 python -> …/python3
8 lrwxr-xr-x 1 gavan admin 9 Jan 9 20:03 wheel -> …/wheel3
Rosebud:~ gavan$ python --version
Python 3.6.0


(Mike McQuaid) #4

Yep, that will work. I’d probably advise sticking it in your $HOME somewhere instead, though.


(Gavan Schneider) #5

If I was the only user this could work but still pose risks — sometimes things aren’t as simple as we would like.

Security models are complex.

Placing nonsystem directories ahead of system directories is a very bad security practice, because it exposes the system to Trojan horses.

http://www.ittoday.info/AIMS/DSM/84-01-18.pdf (~bottom of page 2)

Brew breaks this rule because the trade-off is reasonable. Installed code cannot up-privilege if it is owned and being installed by an ordinary user. The installations go smoothly without need to su anything. But, /usr/local/bin has to go before all others on $PATH otherwise our newly installed versions will never get a run. So far so good.

In attacker mode the ‘game’ is to install a trojan which will get called instead of the real thing. This should be easier to do in non system folders. (Basically if an attacker can get root access they have little need for trojans.) Now the trojan, e.g., “date”, will be called during Terminal sessions, and, if it does not have uid=0 it just invokes /bin/date and nobody notices. Then, during a reboot, a script running as root needs to leave a marker, so we have something like MARKER=$(date ‘+%Y%m%d%H%M%S’), and the trojan gets to run as root, and have some fun no doubt.

So, where’s this going? It’s reasonable to show due diligence and ensure the contents of /usr/local aren’t being meddled with, but it gets a lot more difficult to police the $/HOME/whatever/bin directories. It would be crazy for me to to have ~/gavan/bin at the top of the system wide $PATH. And since I have the admin role I need to exercise superuser privileges now and again. So my example trojan could do quite well whenever I run a script which invokes it. This applies whenever and however my $HOME/bin added to the front of $PATH, e.g., in $HOME/.bash_profile

Putting my personal executables at the end of $PATH is the correct thing to do, but will make it very hard to use my version of the python symlink. My approach is in the middle middle ground:s the modified stuff in a place where I can apply due diligence and check nothing has been altered.

I agree with Mike’s opinion about there being little benefit and some risks in doing all the brewing as a superuser, but the downside Is the implied task of scanning the Cellar and making sure all the labels are correct and none of the contents swapped. Sounds like a job for SHA256 and some plist-fu :slight_smile: