[feature req] use pam_service of sudoers to keep touchid after system upgrading

[gzm55]

Using a custom sudoers.d file and a pam.d conf, we can setup touch id auth for sudo with addition features:

• get rid of .plist files
• do not edit the system managed conf /etc/pam.d/sudo, then the touch id function still works after system upgrading
• support safe and quic recovering for bad pam.d configs for sudo

When installing, the script should generate two files:

1. /etc/sudoers.d/50-pam-service, with the content like this:

Cmnd_Alias PAM_RESTORE=/bin/rm -f /etc/sudoers.d/50-pam-service
Cmnd_Alias PAM_UNINSTALL=/bin/rm -f /etc/sudoers.d/50-pam-service /etc/pam.d/my-sudo
# make restore and uninstall commands still use system sudo profile
Defaults!PAM_RESTORE,PAM_UNINSTALL pam_service = sudo
# restore command does not require password, we can restore as long as sudo can find sudo pam profile
# the {admin-user-name} should be replaced with a real user name
"{admin-user-name}" ALL=(ALL) NOPASSWD: PAM_RESTORE
# use custom pam_service for all users
Defaults pam_service = my-sudo
# use custom pam_service for specify users
# the {admin-user-name} should be replaced with a real user name
#Defaults:"{admin-user-name}" pam_service = my-sudo

2. /etc/pam.d/my-sudo, with the content like this:

# reattach to user gui session: https://github.com/fabianishere/pam_reattach
# remove the following line if pam_reattach is not installed, and the installing script has to detect the absolute path of pam_reattach.so
auth       optional       /opt/homebrew/lib/pam/pam_reattach.so
# auth via touch id: https://github.com/artginzburg/sudo-touchid
auth       sufficient     pam_tid.so
# include system sudo policy
auth       include        sudo
account    include        sudo
password   include        sudo
session    include        sudo

we can add more sudo auth features in /etc/pam.d/my-sudo. when fails, the user with name {admin-user-name} can quickly restore the default sudo auth method by running

sudo /bin/rm -f /etc/sudoers.d/50-pam-service

[sonykphilip]

This is the way.

[artginzburg]

Now that Sonoma is out with sudo_local (#18), it seems pointless to implement this. @gzm55 do you think it's still relevant?

[gzm55]

sudo_local is almost the way in this issue, the latest /etc/pam/sudo contains the line as the first auth line:

auth       include        sudo_local

For the newer OS (>=14), we should create/edit the /etc/pam/sudo_local (a fixed magic path) to enable all the plugins (tid, pam_reattach, etc.) we needed without any include lines.

In the sudoers part on the newer OS, we don't need to enable another pam_service, but we should better keep the restore commands using a safe pam_service and NOPASSWD to disable a bad /etc/pam/sudo_local.

[sonykphilip]

+1 to this. The first thing that came into mind when comparing this method vs. sudo_local was the lack of a safe recovery mechanism.

But this would still be the right way on pre-sonoma machines. Maybe change it to /etc/pam.d/sudo_local instead of /etc/pam.d/my-sudo so that its ready for Sonoma+(?)

Also, it would have been nice if "pam_reattach" and "pam_watchid" could somehow be chosen as an option during install, instead of having to manually add that too. Wishful thinking on my part.

[gzm55]

But this would still be the right way on pre-sonoma machines. Maybe change it to /etc/pam.d/sudo_local instead of /etc/pam.d/my-sudo so that its ready for Sonoma+(?)

The hard part for pre-sonoma is that the OS will be upgrade to sonoma, and the include direction need to be reversed after upgrading:

• on osx 13: /etc/pam.d/my-sudo include lines from /etc/pam.d/sudo
• on osx 14: /etc/pam.d/sudo include lines from /etc/pam.d/sudo_local

I'm afraid the cycling includes of sudo and sudo_local would introduce some troubles.