3 ms·

>Changing a shared system-wide path or installing shared system-wide files owned by a user is so fundamentally borked that you should immediately reject anythin

>Changing a shared system-wide path or installing shared system-wide files owned by a user is so fundamentally borked that you should immediately reject anything offered by anyone who suggested to do that. I don't think that's fair to the homebrew developers. They chose a justifiable tradeoff - as you said most mac systems are single user systems and their design offers better protection to a far larger group of users. When you run `brew install ffmpeg` you are running an arbitrary ruby script from Homebrew git repo and it's probably better that it doesn't run as root. I can't see how that is bad advice; I'd argue that the opposite - sticking to "tradition" despite the changing the landscape of how personal devices have changed security is the broken mindset. I'm sure most macOS users are far more concerned about an arbitrary script exfiltrating their keychain than some contrived multi-user setup where another user installs a keylogger in the system path.

Brian_K_White 6y ago
"contrived" is not an excuse for doing something wrong. All programming, heck all system design of any form, programming, mechanical hardware, legal process, is made of ensuring that situations are handled, including both the obvious ones you thought of and the ones you didn't think of. All "corner cases" could be described as "contrived", yet they happen a million times an hour. "Contrived" is a contrived rationale to ignore something you should not ignore for mere convenience. "contrived" is just a silly and empty accusation, and no argument. If you are in a conversation where the subject deals in probabilities or percentages, then you can talk about liklihood. Having say 1% of customers fail to navigate a subway map is better than having 8% fail. And some contrived example problem like the map needs to be only in shades of green because what if you're colorblind... the contrived nature of the problem matters because the problem deals in percentages where 99% is better than 92%. But in system design (such as application programming or os design, especially the lowest most basic security aspects, things are only possible or not-possible. There is no "likely" and no "contrived". If you can "contrive" an example that invalidates a design, then you have invalidated the design, period. If you cannot contrive an example, then you still have not proven the design, merely you have failed to IN-validate it, yet. The /Applications directory is not equivalent to the /usr/local tree, or any other part of the system. The /Applications dir itself is owned by root, and a user may not change it to be owned by theirself, and a user may only write within it because they are a member of the "admin" group. Until recently, the homebrew installer actually changed the ownership of /usr/local itself (or created it, I don't remember if it maybe didn't exist by default and was created by brew sometimes) rather than just some of the stuff under it. They only changed when forced to, when Apple started more actively protecting system components from modification a couple years ago. If it's ok for shared system components to be owned by joe random user, then why did Apple start protecting /usr/local? For that matter why can't joe random user replace /bin/cp with his own copy, or the kernel? /usr/local/bin/mycp is (or rather should be, and is on sane sysyems) just as much a protected part of the system as /bin/cp. It's only different in that it's locally added to this machine and didn't come on the install cd, and may have different behavior than other parts of the system expect etc. But it's not "steve's" either. A "mycp" owned by "steve" should only exist in /home/steve (or /Users/steve on mac). If brew installed everything in /Applications/Brew.app that would be ok too, because then it would be just doing what other apps do, and because /Applications is a special case which has extra handling by other means than merely the traditional unix file ownerships. That would still be mildly broken because it would mean that all users could use the brew binaries and other assets, but only the installing user could modify them. That is fine for most apps which do not modify their internal contents, but brew is essentially a whole system itself, and it's contents are modified during normal use. A theoretical Brew.app is not like Calculator.app So, the only sane way to do it is to install as the user somewhere within the users own domain (their home dir) or install in a system-wide shared place and require sudo for any "brew update" or "make install". If it were all owned by a special user and/or group "brew" (not whatever random user happened to do the install), that would be sane too, but not necessary.

Brian_K_White 6y ago

"contrived" is not an excuse for doing something wrong. All programming, heck all system design of any form, programming, mechanical hardware, legal process, is made of ensuring that situations are handled, including both the obvious ones you thought of and the ones you didn't think of. All "corner cases" could be described as "contrived", yet they happen a million times an hour. "Contrived" is a contrived rationale to ignore something you should not ignore for mere convenience. "contrived" is just a silly and empty accusation, and no argument. If you are in a conversation where the subject deals in probabilities or percentages, then you can talk about liklihood. Having say 1% of customers fail to navigate a subway map is better than having 8% fail. And some contrived example problem like the map needs to be only in shades of green because what if you're colorblind... the contrived nature of the problem matters because the problem deals in percentages where 99% is better than 92%. But in system design (such as application programming or os design, especially the lowest most basic security aspects, things are only possible or not-possible. There is no "likely" and no "contrived". If you can "contrive" an example that invalidates a design, then you have invalidated the design, period. If you cannot contrive an example, then you still have not proven the design, merely you have failed to IN-validate it, yet. The /Applications directory is not equivalent to the /usr/local tree, or any other part of the system. The /Applications dir itself is owned by root, and a user may not change it to be owned by theirself, and a user may only write within it because they are a member of the "admin" group. Until recently, the homebrew installer actually changed the ownership of /usr/local itself (or created it, I don't remember if it maybe didn't exist by default and was created by brew sometimes) rather than just some of the stuff under it. They only changed when forced to, when Apple started more actively protecting system components from modification a couple years ago. If it's ok for shared system components to be owned by joe random user, then why did Apple start protecting /usr/local? For that matter why can't joe random user replace /bin/cp with his own copy, or the kernel? /usr/local/bin/mycp is (or rather should be, and is on sane sysyems) just as much a protected part of the system as /bin/cp. It's only different in that it's locally added to this machine and didn't come on the install cd, and may have different behavior than other parts of the system expect etc. But it's not "steve's" either. A "mycp" owned by "steve" should only exist in /home/steve (or /Users/steve on mac). If brew installed everything in /Applications/Brew.app that would be ok too, because then it would be just doing what other apps do, and because /Applications is a special case which has extra handling by other means than merely the traditional unix file ownerships. That would still be mildly broken because it would mean that all users could use the brew binaries and other assets, but only the installing user could modify them. That is fine for most apps which do not modify their internal contents, but brew is essentially a whole system itself, and it's contents are modified during normal use. A theoretical Brew.app is not like Calculator.app So, the only sane way to do it is to install as the user somewhere within the users own domain (their home dir) or install in a system-wide shared place and require sudo for any "brew update" or "make install". If it were all owned by a special user and/or group "brew" (not whatever random user happened to do the install), that would be sane too, but not necessary.