7 ms·

It really feels like Apple's OS updates have started to become user hostile in an attempt to "iOS-ify" MacOS.

donarb 7y ago
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.
- vorpalhex 7y ago
  Through a super flag that can't ever be revoked even by sudo?
  - Wowfunhappy 7y ago
    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. You can also selectively disable parts of SIP.
    - thawaway1837 7y ago
      But this behavior makes no sense at all. 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?
      - jackhack 7y ago
        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. That's "user hostile" in my book.
        ridiculous_fish 7y 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?
    - overgard 7y ago
      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?).
      - Wowfunhappy 7y ago
        > 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.
        overgard 7y ago
        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.
- thawaway1837 7y ago
  Because you cannot revoke that access either through GUI tools, or through sudoed terminal commands. I think this is most likely a bug, but if not, then it is definitely user hostile.
  - saagarjha 7y ago
    I doubt this is a bug; a similar feature has been available in the app sandbox for a while.
  - deleted 7y ago
    [deleted]
  - lolsal 7y ago
    I don't think this behavior is user hostile.
jandrese 7y ago
This isn't really user hostile. The opposite really, stuff just works. It's possibly security hostile though, and admin hostile, especially since these out of band permissions are apparently very difficult to revoke. As an admin nothing gives me heartburn more than when the system does some sort of magic to make something just work, because I know whatever that process is will be poorly documented and difficult to manage.
- jdjdjjsjs 7y ago
  It still doesn't make sense. If this is the better approach, then why isn't it the default. Why is it enabled (in a way that is extremely difficult to reverse) by copy pasting something in the Terminal? I'm pretty sure this is a bug that will likely be resolved in a couple of minor updates. Edit: Also, this is extremely user hostile. And it is security hostile. The user and securoty hostile bit isn't giving access when the user pastes a location in the terminal. The hostile bit is completely ignoring the users action when they subsequently try to disable access through the File Access dialog. And it's security hostile because the OS is making it difficult to remove access, not enable access.
  - jandrese 7y ago
    It's hard to imagine how this could be accidental behavior. It is much too specific. The only way I could see it being a bug (or incomplete feature) is if maybe there's supposed to be a prompt asking if you want to grant permission first that isn't working. And maybe some sort of permission manager that lets you add/revoke said permissions without a laborious reboot into a diagnostic tool.
    - jasonlotito 7y ago
      > It's hard to imagine how this could be accidental behavior. Ooops, I meant to drag it onto my desktop, but I accidentally dropped it onto my terminal. It's very easy to imagine how this could be accidental behavior.
      - 7y ago

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.

vorpalhex 7y ago
Through a super flag that can't ever be revoked even by sudo?
- Wowfunhappy 7y ago
  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. You can also selectively disable parts of SIP.
  - thawaway1837 7y ago
    But this behavior makes no sense at all. 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?
    - jackhack 7y ago
      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. That's "user hostile" in my book.
      - ridiculous_fish 7y 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?
  - overgard 7y ago
    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?).
    - Wowfunhappy 7y ago
      > 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.
      - overgard 7y ago
        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.
thawaway1837 7y ago
Because you cannot revoke that access either through GUI tools, or through sudoed terminal commands. I think this is most likely a bug, but if not, then it is definitely user hostile.
- saagarjha 7y ago
  I doubt this is a bug; a similar feature has been available in the app sandbox for a while.
- deleted 7y ago
  [deleted]
- lolsal 7y ago
  I don't think this behavior is user hostile.

jandrese 7y ago

This isn't really user hostile. The opposite really, stuff just works. It's possibly security hostile though, and admin hostile, especially since these out of band permissions are apparently very difficult to revoke. As an admin nothing gives me heartburn more than when the system does some sort of magic to make something just work, because I know whatever that process is will be poorly documented and difficult to manage.

jdjdjjsjs 7y ago
It still doesn't make sense. If this is the better approach, then why isn't it the default. Why is it enabled (in a way that is extremely difficult to reverse) by copy pasting something in the Terminal? I'm pretty sure this is a bug that will likely be resolved in a couple of minor updates. Edit: Also, this is extremely user hostile. And it is security hostile. The user and securoty hostile bit isn't giving access when the user pastes a location in the terminal. The hostile bit is completely ignoring the users action when they subsequently try to disable access through the File Access dialog. And it's security hostile because the OS is making it difficult to remove access, not enable access.
- jandrese 7y ago
  It's hard to imagine how this could be accidental behavior. It is much too specific. The only way I could see it being a bug (or incomplete feature) is if maybe there's supposed to be a prompt asking if you want to grant permission first that isn't working. And maybe some sort of permission manager that lets you add/revoke said permissions without a laborious reboot into a diagnostic tool.
  - jasonlotito 7y ago
    > It's hard to imagine how this could be accidental behavior. Ooops, I meant to drag it onto my desktop, but I accidentally dropped it onto my terminal. It's very easy to imagine how this could be accidental behavior.
    - 7y ago