To achieve this, it sets up a hierarchy under /opt (which is the annoying bit, because this directory is not on $PATH by default, nor is picked up by compilers without some prodding). Philosophically, MacPorts has a very different perspective of how it should work: it tries to prevent conflicts with the system as much as possible. MacPorts, on the other hand, swings so far in the other direction that it’s actually borderline inconvenient to use in some sense. ~/brew) is useful as a case where dropping sudo actually makes sense. This is a shame, since the ability to install packages to a local path (e.g. Installing Homebrew to another prefix would solve some of these problems, but unfortunately this is broken to the point that Homebrew itself recommends that you don’t do this. Ls " " # move along, nothing to see here fiīoom, now ls is booby-trapped for everyone on the system. #!/bin/bash if ] thenĮcho pwned # you didn't happen to run "sudo ls", did you? else Consider a malicious shell script running with the privileges of the current user (perhaps something you found on the internet?) that makes a file at /usr/local/bin/ls: Not only does this make Homebrew completely unusable for multi-user systems, it opens up a security hole (actually, multiple): with /usr/local/bin being shared (and the first in $PATH!!), it’s not hard to see how changing the permissions on this directory leads to trouble. Telling users to use sudo as a hammer to smash permissions “issues” that arise as a result of the system trying to fix damage caused by supposedly “sudo-less” software is quite ironic (and this is a bad practice in and of itself: it’s teaching users to fix problems by blindly running sudo chown -R). If you’re unsure what to do, you can run cd /usr/local & sudo chown -R $(whoami) bin etc include lib sbin share var opt Cellar Caskroom Frameworks. If commands fail with permissions errors, check the permissions of /usr/local’s subdirectories. Homebrew’s troubleshooting guide lists these out, because reinstalling macOS sets the permissions back to what they’re supposed to be and breaks Homebrew in the process: After rootless was introduced, it moved most of its files to subdirectories however, to maintain the charade of “sudo-less” installation, Homebrew will still trash the permissions of folders inside /usr/local. This decision has important consequences for both security and usability, especially with the advent of System Integrity Protection in OS X El Capitan.įor quite a while, Homebrew essentially considered itself the owner of /usr/local (both metaphorically and literally, as it would change the permissions of the directory), to the point where it would do things like plop its README down directly into this folder. This fundamentally is a very bad idea: package managers that install software for all users of your computer, as Homebrew does by default, should always require elevated privileges to function correctly. Homebrew makes several questionable design decisions, but one of these deserves its own section: the choice to explicitly eschew root (in fact, it will refuse to work at all if run this way). These differences become immediately evident once you start using them: I personally feel that MacPorts is clearly the better architected, more mature package manager of the two. While both MacPorts and Homebrew try to solve the same problem, they really are designed quite differently from each other. In case it isn’t obvious from the introduction, it’s these two that we’ll be talking about. MacPorts, on the other hand, was released in 2002 as part of OpenDarwin, while Homebrew was released seven years later as a “solution” to many of the shortcomings that the author saw in MacPorts. Using Debian’s dpkg and APT as its backend, Fink is still actively maintained, though I haven’t looked at it very closely. It’s not surprising that one of the first projects to solve the problem of package management, Fink, was created very early, with its initial releases predating that of Mac OS X 10.0 by several months. Package management on macOS has a somewhat complex history, mostly owing to the fact that unlike most Linux distributions, macOS does not ship with a default package manager out of the box. A brief history of package managers on macOS I’ve been doing a lot of thinking about the state of package management on macOS, and here’s what I’ve come up with based on my experiences using both and interacting with their development communities. A couple of months ago, I uninstalled Homebrew and migrated my configuration to MacPorts.
0 Comments
Leave a Reply. |