MacOS 10.11 change permission of "SystemVersion.plist"

Same problem on my end. It looks like a lot of system locations (i.e. /usr/share/) are being rejected from file-write-create by sandboxd now. Is this intended going forward?

This is the Error Message !

http://www.loeschl.com/download/Error.png

Check out the WWDC 2015 session 706 "Security and Your Apps". It explains this new System Intergrity feature and how to disable it for development purposes. The general outline is that anything under /System and several standard unix location (like /usr/bin, /usr/lib /usr/share etc.) can only be modified under special conditions.

Thank you. I will Check it 🙂

I dont want to watch 50 Minutes about it, but dont find a solution for my problem. Security is ok, but it must be possible for Developers to can change some things for testing.

I did find the solution !!

The solution is to disable the rootless feature !!

Run this in the Terminal:

sudo nvram boot-args="rootless=0 kext-dev-mode=1"

Honestly, disabling rootless^H^H^H^H^H^H^H^H system integrity protection seems like the wrong answer here. In situations like this, where I need to test on multiple versions of the OS, I set up VMs for each OS version I support and then run my tests on the VMs. That doesn't require disabling SIP /and/ gives you a better representation of the OS as it's deployed on user systems.

Share and Enjoy

--

Quinn "The Eskimo!"

Apple Developer Relations, Developer Technical Support, Core OS/Hardware

It was for me important that i can use my Tool for testing of our Printer & Scannerdriver and other Softwaretools.

Never i will try it in a VM, cause i need the full power of my Mac for it. I dont want to open a Indesign File with 2 Gig Data and the to print it from a VM.

Here my Tool if you want to know it. Translation in differend languages on the Page possible.

http://osx.loeschl.com/?p=1347

The supported way to disable System Integrity Protection in those cases where it's truly necessary is to boot into the Recovery partition and turn System Integrity Protection off from there with the csrutil tool.

$ csrutil

usage: csrutil <command>

Modify the System Integrity Protection configuration. All configuration changes apply to the entire machine.

Available commands:

disable

Disable the protection on the machine. Requires a reboot.

enable

Enable the protection on the machine. Requires a reboot.

status

Display the current configuration.

The kext-dev-mode and rootless boot-args are being removed from OS X El Capitan and will no longer work.

--gc

This (modifying the version plist) is probematic for me because I need to determine what is broken in our existing ecosystem (including the installer and system configuration needs) under the new OS version before I know where I need triage. By modifying the version to install our current tools and app, I can do this. Yes, I can build and run fresh on the platform without the installing the package, but that takes out a big part of the user-proof testing. The developer can always get their app to run .

I don't appreciate what I've run into so far, but I'm in a "the jury's out" mode on SIP until we get closer to user release. I already know of 3 universities that will turn this off on every roll-out as soon as they have to install 10.11.

One question that I really don't expect to be answered - why not use a skeleton overlay system like some ***BSDs that reset the protected environment paths on reboot so that even an exploit can be undone by a simple reboot? If you want to modify a skeleton level file, reboot into the recovery volume, make the mods, reboot - et voila! Only mods made by the local system owner stick around.

As of 10.11 root being the ultimate authority on the machine is no longer the case. As the invention of SIP and other changes to 10.11 basically created an abstraction layer over the UNIX system. Apple is pushing toward our desktops/servers being more like an iPhone because of the increase of malware and for 'security reasons'. There were tons of drivers that were invalidated by this release as well.

I agree w/ all of you in the past I would from time to time change my SystemVersion.plist to get around installers that check the version of the OS but, don't need to....

I think this is just the beginning of us loosing more and more control over our workstations/servers. If you noticed w/ the upgrade of 10.11 they even removed and actually reorganized the filesystem and lots of other things. This was a rush response to security issues as SIP and these other utilities were not ready for the prime time. I personally believe Apple should of guaged their user base's response to these changes better as well. Apple has never been fond of the power users, those of us who debug, write drivers and real developers.

Looks like apple is doing to MacOS what oracle did to Solaris/SunOS which is essentially killing all outside OS development and CDL'ing and hiding as much of the core functionality if possible from the user.

Good luck!

Honestly - it's the mystery of the system that both intrigues - and - worries me. I'm used to Debian / Linux systems and how they operate. I've used mabooks for 8 years, and I didn't even think about the systems folder - everything I used for development was in /usr/local - so 6 months into my developer license they announce 10.11 and SIP - so naturally I wanted to see what they where protecting and how it was being implemented. No clue how it works. I assume it's designed to prevent malicious code from being installed - but implementjng it like this a double edged sword because if the security is bypassed somehow then not only would it be impossible to remove - it'd be nearly impossible to detect. They should at least give us the option of setting a 3rd firmware password for SIP because even disabling won't give you full access