[yuriyguts]

I love using sudo with Touch ID and have been using this trick for years. The only inconvenience is that the PAM configuration always gets reverted by OS updates.

I wrote a small tool to mitigate this by configuring PAM on system startup: https://github.com/YuriyGuts/persistent-touch-id-sudo

[eevilspock]

I'm leery of configuring user code to automatically modify system files, especially security related ones. I think your tool should at least have an option to ask user confirmation, perhaps showing the expected file diff, before making its change. https://github.com/YuriyGuts/persistent-touch-id-sudo/issues...

System updates are not frequent. I prefer doing it manually, and just automating a notification that it needs to be redone. I added this to my `.bashrc`:

    if ! grep -q "pam_tid.so" /etc/pam.d/sudo ; then
      echo "touch ID no longer enabled for sudo. Insert the following line as line 2 in /etc/pam.d/sudo:"
      echo "  auth   sufficient  pam_tid.so  # enables touch id auth for sudo"
    fi

[yuriyguts]

This is a reasonable concern. Although, whenever security-convenience tradeoff is involved, different users will inevitably have different preferences and tolerance for automation. Some will prefer to do things manually, while others will prefer something that "just works" for them.

[eevilspock]

That's why I said "should at least have an option". And even when that option is enabled, it still "just works", but with a simple user confirmation and perhaps a visual of the file before and after (What if Apple changes the file format?).

I think you overstate this tradeoff in this case since there is a win-win solution.

[saagarjha]

System updates are pretty frequent if you’re on a developer train.

[rollcat]

Seems like something that would be worth generalising a little bit, perhaps merge /usr/local/etc into /etc every boot? Probably could be as simple as "rsync -r /usr/local/etc/ /etc/".

[chii]

you'd want a patch file instead may be? If something new was added to /etc, you'd not want to overwrite it

[rollcat]

OpenBSD has sysmerge (https://man.openbsd.org/sysmerge), Debian's dpkg will also prompt to accept/reject changes; this probably would be the ideal solution, but macOS doesn't give you an opportunity to implement such a scheme, since an upgrade just overwrites all user changes unconditionally.

Patches are harder to use than plain files, since you need to maintain a source and a destination to diff against, and applying them can occasionally fail, requiring the user to resolve.

I think overriding configuration in /etc is one of those cases where the user's intent is very clearly "I know what I'm doing, please get out of my way", and other unices are built to respect that. macOS assumes it's the other way around, and ends up doing crazy stuff like overwriting "PasswordAuthentication" to "yes" in sshd_config on every upgrade.

Running rsync to just overwrite the configuration is probably too simplistic. Maybe the tool could detect that a file was overwritten by an upgrade, and make a backup (sshd_config.upgrade, and so on).

I think I'm just going to write it now.

[chii]

> Maybe the tool could detect that a file was overwritten by an upgrade, and make a backup

That's probably a good compromise between giving the user the power, but not letting them shoot themselves in the foot!

[rollcat]

Would you like to have a look? https://github.com/rollcat/upmerge