diff options
| -rw-r--r-- | source/blog/2015-10-14-sip-for-the-greater-good.md | 12 |
1 files changed, 12 insertions, 0 deletions
diff --git a/source/blog/2015-10-14-sip-for-the-greater-good.md b/source/blog/2015-10-14-sip-for-the-greater-good.md new file mode 100644 index 00000000..3dbf7b24 --- /dev/null +++ b/source/blog/2015-10-14-sip-for-the-greater-good.md @@ -0,0 +1,12 @@ +--- +title: "SIP — For the Greater Good" +date: 2015-10-14T17:07:24-07:00 +date_display: October 14, 2015 +--- +In recent months I wrote a few thousand words lamenting Finder and [SIP](https://en.wikipedia.org/wiki/System_Integrity_Protection) on El Capitan. See [The sad state of Finder on El Capitan](/blog/2015-07-30-the-sad-state-of-finder-on-el-capitan.html) and [its follow-up](/blog/2015-10-14-follow-up-the-sad-state-of-finder-on-el-capitan.html). + +For the record, I'm not blaming SIP. It does deal a serious blow to people who in-memory patch stock applications (and there's a good discussion about the creativity aspect on [ATP episode 128](http://atp.fm/episodes/128)), but the general public — at least more than 95% of users — should not be negatively affected, at least not in the short term. And I can understand why SIP protection comes at this time. Macs used to be safe, but in recent years we are seeing real world exploits increasingly more often. History has shown that technically-challenged users simply can't be entrusted with admin accounts, they are too willing to give their passwords to shady software downloaded from shady corners of the web (and sometimes even renowned corners get hacked). But they are given admin accounts anyway (there has to be someone knowing the admin password), so Apple has to come up with ways to protect them. SIP is a pretty good response. + +SIP is also good for new tinkerers. When I first started to tinker with the command line, I wasn't aware of package managers and I wasn't messing inside virtual machines, so I would download packages from official websites, then manually compile and install them to my daily system. Some packages didn't respect the `/usr/local/bin` (and `include`, `lib`, `libexec`, `share`, etc.) convention and insisted on `/usr/bin`; some others used funny locations like a standalone subdirectory of `/usr/local`; and when things don't work (e.g., can't find libraries when building — at that time I'm not familiar with `CFLAGS=-I` yet), I would explictly change `PREFIX` (probably to `/usr`) and try again. That way, over a period of a few months, I ended up with a genuinely messed up `/usr`, with all kinds of stuff everywhere. I probably overwrote quite some binaries shipped with the system. The configuration kind of worked but was pretty fragile. In the end I reinstalled the system, and started to (loosely) follow FHS ([Filesystem Hierarchy Standard](http://www.pathname.com/fhs/)) and use package managers (first MacPorts, then Homebrew). Good times. If I were to start tinkering today, I would certainly meet some barriers early on, but I would probably also learn the good practices earlier. + +SIP is clearly the future, and I don't blame it. I just hope we don't see a vulnerability in the implementation soon. |