25 ms·

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 update

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 https://github.com/YuriyGuts/persistent-touch-id-sudo

rollcat 4y ago
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 4y ago
  you'd want a patch file instead may be? If something new was added to /etc, you'd not want to overwrite it
  - rollcat 4y ago
    OpenBSD has sysmerge (https://man.openbsd.org/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 4y ago
      > 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 4y ago
        Would you like to have a look? https://github.com/rollcat/upmerge https://github.com/rollcat/upmerge
eevilspock 4y ago
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/1 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 4y ago
  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 4y ago
    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 4y ago
  System updates are pretty frequent if you’re on a developer train.

rollcat 4y ago

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 4y ago
you'd want a patch file instead may be? If something new was added to /etc, you'd not want to overwrite it
- rollcat 4y ago
  OpenBSD has sysmerge (https://man.openbsd.org/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 4y ago
    > 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 4y ago
      Would you like to have a look? https://github.com/rollcat/upmerge https://github.com/rollcat/upmerge

eevilspock 4y ago

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/1 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 4y ago
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 4y ago
  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 4y ago
System updates are pretty frequent if you’re on a developer train.