How is this user hostile? The behavior described is that the Terminal is granted access to the file automatically when the user specifically tries to access the file in Terminal.
The purpose of System Integrity Protection is to create a privilege level that not even superuser has access to.
Luckily, if you’re an experienced user you can boot into recovery mode and permanently disable it, so it will never bother you again. Takes five minutes. Then sudo will be able to do anything.
An accidental copy/paste means you cannot return the permissions to their default state without disabling SIP. Presumably the default permission is a good one, otherwise, if it’s so terrible that it’s a good idea to make it so difficult to go back to it, then why is it the default?
exactly. It's user hostile to correct/undo the action. A 2 second drag-drop mistake requires the following to correct it:
1. realize mistake / stop-everything-you're-doing
2. reboot to recovery mode
3. change SIP setting --> disabled
4. reboot to normal OS
5. delete attribute you never wanted
6. reboot to Recovery again
7. re-enable SIP
8. reboot to normal OS and get back to work if you can remember what you were even doing 20 minutes ago.
Why would you bother to do any of that? If you accidentally allow an unsandboxed app to access ~/Downloads without prompting, it's just like using a Windows or Linux or Mojave system. Who cares?
Creating a privilege level the user of the computer doesn't have access to sounds user-hostile to me. I'm all for security, but it's my computer. (I know you can reboot/turn it off etc., but come on, I shouldn't need to reboot my computer into some sort of recovery mode to remove an attribute on a file because I dragged a file. What if I was dragging it somewhere else and my hand slipped off the trackpad?).
> but come on, I shouldn't need to reboot my computer into some sort of recovery mode to remove an attribute on a file
To be clear: you need to reboot your computer once, and from then on, sudo will always have full permission to do anything. You won't ever have to boot into recovery mode again unless you buy a new computer.
You don't have to like the default, but when it's so darn easy to make your system work the way you'd like, I find it really hard to complain.
Some guides will recommend making SIP-protected changes from within recovery mode as an alternative to disabling SIP permanently. But you absolutely don't have to do that.
I know I can turn it off, but that's not the point. The point is that, if the standard advice for when it does something completely surprising and weird is "just turn it off", then it's a bad security feature.
Granted I'm biased, because my experience with SIP has entirely been that it just breaks things and makes it impossible to fix it. Here's an example of an awful thing it did: if you happen to be using the builtin system python in an older version of macOS, and then you upgrade macOS, certain modules become unusable because the .pyc files they generated on older versions become completely locked by SIP, and the only way to fix it? Yeah, you guessed it, restart it and disable it. You might say, well, don't use the system python. Sure, but python installation is a mess on macOS anyway, and it wasn't my machine this was causing issues with, it was everyone else in the department. I just had to fix it. Also, it's frustrating as hell because essentially I'm disabling it to prevent macOS from screwing with itself. Which is entirely antithetical to the purpose of the feature in the first place (protecting os files).
If the solution is always "turn it off", that's what people are going to do, and the entire feature becomes a frustrating waste of time.
Also, I would argue there's nothing "easy" about having to reboot into a recovery mode to do this. It may not be hard, but it's a pain in the ass and totally pointless.
My main issue with this is that it makes testing/debugging of certain classes of bugs very tedious.
The only way to reliably simulate what happens on a typical user machine (with SIP enabled) is to start with SIP enabled, run a test scenario that involves these permissions, then reboot and disable SIP, clear the permissions that changed, then reboot and enable SIP again before running the test scenario again.
Btw for the cowardly downvoters, are you really happy that Apple is reserving privileges on your computer for themselves? SIP isn't about giving you control, since you have no control over SIP, SIP is about Apple locking down what you can do with your own computer. You can have security without doing that (see: linux, bsd, etc.). There's no legitimate technical reason for the way SIP is implemented, it's a business decision by Apple. You should be irritated with Apple for this non-functional garbage.
I don't want to become a broken record, but how is it an example of Apple "locking down what you can do with your own computer" when they also give you the ability to remove the lock?
I truly don't understand why this appears to upset you so much. I realize that disabling SIP is a very minor inconvenience but you've spent considerably more time writing these comments than it would take to disable SIP.
Now, if we were talking about the T2 chip and replacing your SSD, I'd be taking a totally different tune here. There's also a certain other Apple operating system that is considerably more locked down, in very annoying and non-optional ways...
