My understanding is that the whole reason for running the outer commands as sudo is so that the inner build/install commands can be run in a far more restricted environment. Because brew runs as your own user, every build has access to your entire home directory, the whole homebrew folder, etc. It's nice in principle to not have to "trust" any of homebrew with sudo, but in reality, the trust surface area is far larger. With MacPorts, you only have to trust the tooling, not the individual package definitions (though obviously the calculus does change slightly when bottles are in the picture, since then the build/install is happening elsewhere).
I am confused by this. sudo seems like a far larger surface area than running as me. If it's just me then it's just me, but if it's sudo, then it's the entire box.
It depends whether you trust the tool maintainers more than the package definition maintainers. I certainly would. But don't take my word for it— here's a MacPorts developer explaining the sandboxing of builds:
> Directories listed in multiple users' $PATH that are writable without superuser privileges can be used for attacks (e.g., by placing a sudo binary that will log the password there). The same can be done by malicious software running as your user in order to get your password
Yikes. That particular attack did not occur to me.
> inner build/install commands can be run in a far more restricted environment
As I seem to remember it, homebrew rankles if you use sudo but also complains if you’re not an admin account, which struck me as ironic and irritating all at once, and means that xkcd isn’t quite as relevant.
> every build has access to your entire home directory, the whole homebrew folder, etc.
Isn't this just whataboutism though? Yes that's potentially a problem but it's an orthogonal one. So not really relevant to this discussion.
A hypothetical solution to the problem in the linked XKCD would be to somehow prevent an attacker accessing your bank, it would not be to allow an attacker to install drivers without your permission.
> With MacPorts, you only have to trust the tooling, not the individual package definitions (though obviously the calculus does change slightly when bottles are in the picture, since then the build/install is happening elsewhere).
This calculus change is basically my primary concern.
Of course it's not ideal that Homebrew apps have access to everything in my Home, but that's still better than them having access to everything on my system.
The point is that they wouldn't. Only the core brew utility would, because in almost all cases, it would be immediately downgrading itself to either a dedicated homebrew user, or in the case of builds, to a nobody user who does its work in /tmp and only has write access to the one install path it has been allocated (which is then chowned to the brew user afterward).
The fundamental issue is that the POSIX user model has no concept of one user being strictly less privileged than another, and therefore all impersonations require root.
And note that the situation on Debian and Ubuntu is much worse than either of these models, because every package has an opportunity to run arbitrary commands as root as part of the postinstall and at various other times during the package lifecycle. So basically you've owned yourself the first time you add some user's random PPA and run `apt dist-upgrade` to pull new versions from it.
Relevant: https://xkcd.com/1200/