You are missing the wider point I fear. You seem to be so focused on git that you miss the point that there are other system utilities that are installed in /usr that you might need to patch.
And if I want to troubleshoot something odd, it would be nice to be able to hook in dtrace - without rebooting the server, flipping a switch to disable the "feature", and then troubleshoot my server's issue.
No, I'm just bored of faux-outrage and agenda pushing.
If this is such a critical issue, then reboot your Mac and disable SIP. 5 minutes and done. In the time it's taken you to post all your comments here, you could have fixed it.
[edited to add]
It's not like SIP was a secret - it was one of the major features of El Capitan. Didn't you do any research before upgrading your mission critical server to El Capitan?
You read into what is not there. I know about SIP already, but I've always been surprised about it as it seems pretty flawed to me - it turns out if you can get root access you can easily bypass the "protection" mechanism with a small utility that loads up a kernel extension and bypasses the mechanism anyway.
Incidentally, calm down a bit - you sound pretty outraged yourself!
You might want to address the dtrace issue though - let's say you didn't want to disable the protection that SIP provides in making the /usr filesystem immutable. How do you then run dtrace on system utilities when troubleshooting?
Genuinely curious how you answer that.
Edit to ask another question: another question for you, as you seem to have the answers here: why does Apple install git in a directory that is under the control of System Integrity Protection? Why not under /usr/local? It's not exactly a "system utility" - it's a DVCS and not in any way critical to the running of the system. Hell, I'd not even consider it system software.
And how does Apple do this? The last time I installed the XCode command line tools, I don't recall that I had to reboot my system, so it looks like Apple do indeed have an update mechanism to overwrite the files. In which case it is one exploit away from disabling the file immutability protections afforded by SIP...
From their readme:
"P.S.: 10.11.4 update removed csr_set_allow_all() function used to enable/disable SIP. It means this code does not work on El Capitan 10.11.4 or newer versions when released."
Also even when it did work it needed you to get a Kernel Extension signing certificate from Apple - which they could (probably) revoke pretty easily when they saw it being misused.
Ah, bummer. Thanks for this info, good to know :-)
Of course, there is a utility that sets the flag in recovery mode, unless there is a specially built kernel that only exists in that mode (I'm no OS X expert, there could be) then there must be some way of bypassing the protections. If you can still load a kernel extension then it occurs to me that you can still bypass it.
> Edit to ask another question: another question for you, as you seem to have the answers here: why does Apple install git in a directory that is under the control of System Integrity Protection? Why not under /usr/local? It's not exactly a "system utility" - it's a DVCS and not in any way critical to the running of the system. Hell, I'd not even consider it system software.
I can imagine git might be necessary for applying some updates (on FreeBSD svn is a critical part of the base system, because one way to update is by svn updating the source and rebuilding).
In that case, then git is a vector through which SIP can be bypassed. But it's not used to apply updates as it's part of XCode command line utilities and not the core system.
I'm more amused than upset. You seem rather steamed up there though... Now how about answering my actual question. What if I don't want to turn off SIP but I want to use dtruss to troubleshoot my system?
If Apple truly doesn't want me to use dtruss, then why do they bundle it?
You can use dtruss, you just can't use it on certain binaries. A friend said that you can disable certain parts of SIP to enable functionality like this but I haven't tried myself.
Why would you install Xcode on such a important box?