This becomes a much larger problem if something runs things from /usr/local with increased privileges -- something from launchd run as root, for instance.
I was originally thinking just from the perspective of the active user, but a lot of things get run without the logged in user's knowledge, and with a varying level of privilege.
Ok, yeah, I agree with the original poster of this thread: yikes, time to start chmodding things.
Anyway, back to the dangers of using sudo with Homebrew or Macports. When you build software by hand, without a package manager, do you ever do it as root? I sure don't. But that's exactly what Macports does in its default configuration, and that's what Homebrew would require if you used it with a non-writeable /usr/local. It doesn't have to be a malicious attack, either: just a simple bug in the build system would suffice. For example, if a "clean" rule in a Makefile has a step that looks something like, god forbid, "rm -rf $(BUILD_ROOT)/" and you're running the make as root, you'd better hope that BUILD_ROOT is not defined to be "".
Ideally, all of these package managers would separate the step of building from the step of installing so that you would only need root privileges for the latter, a la Debian's sbuild and friends. Then using a traditional privileged /usr/local directory would be a no-brainer, for the theoretically smaller attack surface it would provide. But none of the Mac packaging systems work like that, to my knowledge. They go for the convenience of a single build+install command. Given that, I'll stick with my user-writable directory and risk the hijacking scenario.
running a fetch as root or blindly changing the permission structure of /usr/local should scare everybody.
I see from the Macports 1.8 release notes that privilege dropping is supported. That's good news, but is it the default? The release notes indicate that you need to pass command-line options to get this behavior. I assume that most people just "sudo port install foopkg".
> blindly changing the permission structure of /usr/local should scare everybody.
On Mac OS X (as of Snow Leopard, anyway), there are no permissions to change, since /usr/local doesn't even exist until you create it. Nothing in the OS itself depends on it or anything that lives there. There's nothing special or privileged, neither by design nor by convention, about /usr/local on Mac OS X. Making it user-writable and using it with a package manager is no different than creating a 2nd home directory for that purpose. If you're running that rare bird that is a multi-user Mac and co-managing packages with other trusted users, then you can simply make it group-writable by those users. It's safer than giving them any sudo privileges.
$ port build wget
$ sudo port install wget
> "is no different than creating a 2nd home directory for that purpose"
except that a million build scripts and make files out there assume /usr/local/ as a default location. setting up something like '/home/shared/' is not a problem, just don't mess with paths that are defaults
> except that a million build scripts and make files out there assume /usr/local/ as a default location. setting up something like '/home/shared/' is not a problem, just don't mess with paths that are defaults
Yet Macports puts everything in /opt/local and that doesn't cause any significant problems. I haven't run across a free software project in years that didn't have support for an install prefix.
Anyway, I should have been more specific: on a Mac, making /usr/local user-writable and using it with a package manager is no different than creating a 2nd home directory for that purpose, from a security standpoint. I agree that putting things in /usr/local is the most logical place to put compiled software (mainly for consistency with one's own scripts that run on multiple platforms), and that's one of the reasons I use /usr/local with Homebrew instead of something in my home directory.