6 ms·

I've been wary of Gatekeeper and SIP as moving Macs towards an iOS-style walled garden, but this is a perfect case of SIP protecting the user from bad software.

userbinator 7y ago
On the contrary, I think that sort of protection just hides problems --- like this one. As a general rule, bugs with the highest impact are also the ones which are most likely to be fixed quickly. If you tested with SIP on, it'd try to remove /var but wouldn't succeed, and you'd think everything is OK when the application's logic is actually faulty.
- xvector 7y ago
  I find that logic faulty. SIP is justified by these incidents. It is not the user’s job to isolate application faults. That is on the part of the app developer’s.
- dkh 7y ago
  Shouldn’t Google also be able to run their tests against a machine with SIP disabled before deploying?
  - kevingadd 7y ago
    Yeah. Pre-SIP OSes were affected too, so they literally just did not test this on any non-SIP version of OS X... or if they did they didn't notice that it was nuking /var. Fresh mac VM wiped after every test run and no 'did we just destroy the OS' smoke test?
    - compuguy 7y ago
      To be fair, none of the Pre-SIP macOS releases are supported by Apple anymore...
      - erichocean 7y ago
        No, it's not fair. SIP can be disabled by the user in modern macOS releases.
- yjftsjthsd-h 7y ago
  If SIP blocks program from accessing system files, shouldn't it alert or something?
  - userbinator 7y ago
    "If the kernel emits a message but no one is around to read it, did it warn?" More seriously, SIP messages do show up in the system logs, which next to no one ever reads unless it's to find out that SIP is preventing something that the user really intended to occur.
  - makecheck 7y ago
    There’s plenty of bad code that fails to check for errors so the OS may well have flagged something here and the program just didn’t know/care. It seems even more likely that the result of unlink() would be ignored (right up there with ignoring printf()), not because it’s the right thing to do but because lazy programmers will assume that failures are incredibly unlikely or unimportant. For example, if the code is a cleanup phase that just wants to remove a list of files, what are the odds that the program dutifully checks that the files actually went away?
    - userbinator 7y ago
      For example, if the code is a cleanup phase that just wants to remove a list of files, what are the odds that the program dutifully checks that the files actually went away? Or, as the reason for the omission of such checks is more likely to be, what to do if something that shouldn't fail, fails? And if whatever you decide to do to handle the error itself also fails? Repeat ad infinitum. To even try to go down that rabbithole is simply a waste of effort and does nothing but introduce unnecessary complexity, to put it bluntly.
- kyralis 7y ago
  That's a great philosophy if your job is QA for the system or application in question. As a consumer? No. I'm not interested in QAing buggy software. I want it to not break my machine.
ryanmarsh 7y ago
I'm happy with Gatekeeper and SIP so far. I don't believe Apple will ever totally wall off macOS like iOS. If I ever truly want to mess around with the OS I'll install Linux. My computing platforms present far more risk to me these days than they did years ago. I need the system integrity protected, I don't want untrusted code running on my Mac. These aren't like the days back when I could self install Linux and expose it to the internet while I configured it.
- xmodem 7y ago
  If anything, iOS is moving in the direction of being less walled off.
  - jbverschoor 7y ago
    It’s not. It’s just providing some hooks. I’m looking forward to iPadOS. All the heaven from iOS in terms of sandboxing and no background tasks (except very well defined). Also Catalina afaik will make an os partition which cannot be tampered with.
- pjmlp 7y ago
  Catalina requires all apps to be notorized, for the time being it is still possible to explicitly allow it on case by cases base, as root. Which is a very good thing on my book. Today it is Google's Keystone, tomorrow it is some scummy app downloaded by a grandpa thinking it was a link actually sent by one of his grandsons about their birthday party.

userbinator 7y ago

On the contrary, I think that sort of protection just hides problems --- like this one. As a general rule, bugs with the highest impact are also the ones which are most likely to be fixed quickly. If you tested with SIP on, it'd try to remove /var but wouldn't succeed, and you'd think everything is OK when the application's logic is actually faulty.

xvector 7y ago
I find that logic faulty. SIP is justified by these incidents. It is not the user’s job to isolate application faults. That is on the part of the app developer’s.
dkh 7y ago
Shouldn’t Google also be able to run their tests against a machine with SIP disabled before deploying?
- kevingadd 7y ago
  Yeah. Pre-SIP OSes were affected too, so they literally just did not test this on any non-SIP version of OS X... or if they did they didn't notice that it was nuking /var. Fresh mac VM wiped after every test run and no 'did we just destroy the OS' smoke test?
  - compuguy 7y ago
    To be fair, none of the Pre-SIP macOS releases are supported by Apple anymore...
    - erichocean 7y ago
      No, it's not fair. SIP can be disabled by the user in modern macOS releases.
yjftsjthsd-h 7y ago
If SIP blocks program from accessing system files, shouldn't it alert or something?
- userbinator 7y ago
  "If the kernel emits a message but no one is around to read it, did it warn?" More seriously, SIP messages do show up in the system logs, which next to no one ever reads unless it's to find out that SIP is preventing something that the user really intended to occur.
- makecheck 7y ago
  There’s plenty of bad code that fails to check for errors so the OS may well have flagged something here and the program just didn’t know/care. It seems even more likely that the result of unlink() would be ignored (right up there with ignoring printf()), not because it’s the right thing to do but because lazy programmers will assume that failures are incredibly unlikely or unimportant. For example, if the code is a cleanup phase that just wants to remove a list of files, what are the odds that the program dutifully checks that the files actually went away?
  - userbinator 7y ago
    For example, if the code is a cleanup phase that just wants to remove a list of files, what are the odds that the program dutifully checks that the files actually went away? Or, as the reason for the omission of such checks is more likely to be, what to do if something that shouldn't fail, fails? And if whatever you decide to do to handle the error itself also fails? Repeat ad infinitum. To even try to go down that rabbithole is simply a waste of effort and does nothing but introduce unnecessary complexity, to put it bluntly.
kyralis 7y ago
That's a great philosophy if your job is QA for the system or application in question. As a consumer? No. I'm not interested in QAing buggy software. I want it to not break my machine.

ryanmarsh 7y ago

I'm happy with Gatekeeper and SIP so far. I don't believe Apple will ever totally wall off macOS like iOS. If I ever truly want to mess around with the OS I'll install Linux. My computing platforms present far more risk to me these days than they did years ago. I need the system integrity protected, I don't want untrusted code running on my Mac. These aren't like the days back when I could self install Linux and expose it to the internet while I configured it.

xmodem 7y ago
If anything, iOS is moving in the direction of being less walled off.
- jbverschoor 7y ago
  It’s not. It’s just providing some hooks. I’m looking forward to iPadOS. All the heaven from iOS in terms of sandboxing and no background tasks (except very well defined). Also Catalina afaik will make an os partition which cannot be tampered with.
pjmlp 7y ago
Catalina requires all apps to be notorized, for the time being it is still possible to explicitly allow it on case by cases base, as root. Which is a very good thing on my book. Today it is Google's Keystone, tomorrow it is some scummy app downloaded by a grandpa thinking it was a link actually sent by one of his grandsons about their birthday party.