• binaries are useable from /opt/local/bin/, i.e. for tesseract

    bin$ which tesseract
    bin$ ls /opt/local/bin/tesseract
    -rwxr-xr-x  1 root  admin  28120 15 Sep  2016 /opt/local/bin/tesseract  
    bin$ ls /opt/local/ | grep bin
    drwxr-xr-x  719 root  admin  24446  6 Aug 19:55 bin 
  • install requires sudo

sudo port install tesseract


bin$ which packer

bin$ ls /usr/local/bin/packer
lrwxr-xr-x  1 myuser  admin  33  7 Aug 14:28 /usr/local/bin/packer -> ../Cellar/packer/1.2.5/bin/packer

bin$ ls /usr/local | grep bin
drwxrwxr-x  41 myuser  admin  1394  7 Aug 14:28 bin
  • install does not require sudo

brew install packer


trimming out other software, this is my $PATH order:

/opt/local/bin  #macports
/usr/local/bin  #homebrew
/usr/bin        #Apple binaries

/usr/loca/bin permissions.

I believe, from https://apple.stackexchange.com/a/261710, that /usr/local/bin, before homebrew, starts out as root-writeable only:

drwxr-xr-x  26 root  wheel  -                 884 Oct 17 03:36 bin


Is there a real difference between those 2 approaches? What happens if either port or brew itself has been hacked? What if the package you're installing has been hacked?

I realize that installing hacked stuff is going to end badly regardless, so, assuming brew/port are OK and the installed package isn't corrupted either, what about the implications of either approach when it comes to other malware trying to alter your system?

Looks to me as if /usr/local/bin is wide open and the binaries there can in effect take the place of any Apple programs. Should I be concerned?

  • IMHO of all your questions only the first one is really up for discussion, because as long as you are willing to install software you are prone to installing malicious software. – Tom K. Aug 14 '18 at 16:23
  • I think you are misreading my comment. While your first question is answerable and specific, your others are not. If you do not narrow down the threats you have described, these questions cannot be answered in a meaningful way. – Tom K. Aug 15 '18 at 17:28

If I am understanding your question correctly, it boils down to:

Homebrew changes the permissions of /usr/local/bin from the default drwxr-xr-x root wheel to the less secure drwxrwxr-x myuser admin. What are the risks?

As you point out, your user (or anyone in the admin group, or any virus that manages to run as you) can now install software, including over-writing default system stuff.

How big of a problem is this?

Multi-user system

On a multi-user system like a server where there are other users logged in, this would be a big problem. I don't have access to a Mac, but I assume my linux box is similar enough; /usr/local/bin is empty (nothing to replace) but

$ echo $PATH

So assuming that other users have the same bash config as me, then it looks in /usr/local/bin first. Therefore I could put a malacious program called ls in /usr/local/bin and the next time someone tries to navigate the filesystem, my code will run inside their user account. The nefarious possibilities are endless.

So I would agree with you that this is a problem on a multi-user server.

Single-user personal computer

For all intents and purposes, there is only one user on your laptop. xkcd illustrates this quite well:

xkcd authorization comic

If an attacker / malware / etc has already gotten inside your account, then they have all your data, it's only a matter of time until they keylog you typing your sudo password, so do you really care whether they install further malware in /usr/local/bin or put it in /home/myuser and add that to your path? The end result is the same.

| improve this answer | |
  • 1
    I agree with your assessment, to a point. Security best practices in Unix world is not to execute programs from current directory, unless specifically told so. i.e. ./foo will work, foo won't even if foo is on current directory. You can add . to $PATH but that's again considered a no-no. The reasoning behind that is to thwart malicious actors that don't have root privileges to write to $PATH directories but can write elsewhere. /us/local/bin being fairly open would seem to go against that intent. – Italian Philosophers 4 Monica Aug 15 '18 at 19:02
  • Uhh, sorta. We're mixing threat models a bit. The "Don't add . to your path" advice is to prevent you from accidentally executing a file that's harmlessly sitting in, for example, your Downloads folder. On the other hand, the threat model implied by /usr/local/bin being writable is that once an attacker has compromised your user account, they can spread malware to root locations. So there's also nothing stopping them from modifying your path via /home/myuser/.bashrc or the environment variable to add whatever folder they want to it. If it's a single-user system, does it matter where? – Mike Ounsworth Aug 15 '18 at 20:20
  • would you say then that the trade-off is increased risk, with macports, at package install, via sudo port install <pkg> vs brew install <pkg>. if pkg is malicious, the sudo at install time makes that worse. but, with brew, the rest of the time the mac is somewhat less locked down, esp wrt multiple users, because of usr/local/bin's more modifiable state? certainly if you mistakenly sudo brew install <pkg> you get a stern warning that it doesn't support sudo as that would be a big risk. – Italian Philosophers 4 Monica Aug 15 '18 at 21:25
  • I feel like we're splitting hairs. Presumably installing brew in the first place needed sudo? It looks like brew changes the owner:group of /usr/local/bin to myuser:admin, which means that admins can now modify /usr/local/bin without needing sudo, but they're admins, so they have sudo anyway, right? Maybe it slightly broadens the damage that can be done with a compromised admin account (maybe ... there's already a lot of damage that can be done...) – Mike Ounsworth Aug 15 '18 at 21:39
  • 1
    ah, yes, I keep on forgetting editing ~/.profile's path. again, this is why I appreciated your insights. – Italian Philosophers 4 Monica Aug 21 '18 at 21:54

The fact that homebrew opens up /usr/local has been one of the reasons for me to move to MacPorts (the other was that MacPorts is better when the target is system-level additions, which may include all kinds of things that require su privileges to install properly so they are installed safely). MacPorts having its own library tree and being fully independent from macOS itself is also important for me, I don't want a macOS update kill my MacPorts additions (as these are services multiple users will depend on them). The price to pay is that you have to do all the LCM and patching (by updating ports).

So, on my macOS Server, where I am running postfix, dovecot, nginx, minio, etc. I am using MacPorts for these.

I started out with homebrew (as it is mentioned everywhere) but as homebrew does not have (probably is pretty much incapable in a reasonable way) postfix, I started looking into MacPorts and got convinced MacPorts is better (for me).

The MacPorts system installs software using su privileges, so you have to trust the fact that the "Port" has not been tampered with using patches or alternate source downloads (MacPorts compiles software, no binaries are downloaded, which I think is an advantage as well). Given that you download Ports from a common repo with reasonably strict access control, the risk is minimal, I think. And the resulting environment on your system in /opt is — as a result — better protected.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.