1. 19
  1.  

  2. 5

    FYI, this has to be applied after every system update.

    1. 1

      This is one of the biggest hurdles I have with macOS. I understand the security concerns and system integrity protections, but messing up my SSH config files is really nasty, and now this.

      1. 1

        I believe Apple treats much of the system as immutable, even if you can technically modify it.

        1. 3

          It’s more of a configuration file issue. The problem is the same as many linux bistros have where they naturally have to ship some default configuration with their packages. If those files are changed by the user and then the package is updated, what happens? Do you wipe the user config? Do you leave the user-modified file alone (potentially breaking the updated package completely if the update has non-backwards-compatible changes)?

          Debian asks the user, but that’s something a mainstream OS like macOS probably can’t afford to do (no user would understand the options and/or their consequences)

          Sometimes, the packages ship with a configuration that allows to include secondary files (for example /etc/sudoers which includes arbitrary files in /etc/sudoers.d in Debian and also macOS) which solves the problem with package-updates when the new package is compatible with the old config files, but of course it still doesn’t help when the new package isn’t compatible with the old files, but that’s rarely the case.

          I’m not aware that PAM has a means for including a directory full of files, so I don’t see how this compromise solution could work for PAM, so Apple would be stuck with either never touching the files after initial install (possibly breaking their intended configuration after an update) or always resetting them after an install (and bring the system to a clean state).

          I totally understand why they do the latter.

          1. 2

            Yeah, I get it. To be clear I’m not that upset about it, but wanted to give people a heads up since the post doesn’t mention it. While this sudo functionality is great in theory, my system ends up not having Touch ID for sudo more often that it does.

            The real solution is just for Apple to add this to the default pam config, but seemingly they have reasons not to.

            1. 1

              RPM usually keeps both files and you can review changes with rpmconf.

              Sometimes, the packages ship with a configuration that allows to include secondary file.

              I’ve been off apple ecosystem for years, but I clearly remember I was very annoyed when minor updates kept deleting exactly these files.

      2. 1

        Unfortunately that doesn’t really work in macOS 11 and later, as this file is SIP protected. I do not know if it is possible to disable it only for one file.

        1. 2

          I’m on 12.4 and could edit the file (via sudo); I have SIP enabled.

          1. 1

            For me it fails, sudo -e /etc/pam.d/sudo results with sudo: /etc/pam.d/sudo: Operation not permitted.

            Ok, after some tests it seems that if I force write, then it works. That mean that you need to open file with sudo vim and then write via :w!.

            1. 3

              Yes, that’s what I did too.

              Perhaps worth mentioning is that if you’ve set up “Log in with Apple Watch”, in addition to TouchID the change also enables the “double-click the watch button to allow” feature. So it can be useful even on a Mac with no TouchID.