4 ms·
> ports does have the separation, you fetch/build as the local user and run install escalated. I see from the Macports 1.8 release notes that privilege droppin
by dhess 17y ago
> ports does have the separation, you fetch/build as the local user and run install escalated.
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.
- bl4k 17y ago$ port fetch wget $ 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
- dhess 17y agoThanks, I didn't know about fetch/build in Macports. > 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.