Not working for me

[frank-laemmer]

Thanks for the nice tool and the blog post. It's unfortunately not working on my computer. Not sure what you would require as debugging info?

I followed the install guides. No errors there. After restart / upgrade the line auth sufficient pam_tid.so in /etc/pam.d/sudo was missing and it didn't asked for touchID.

• macOS 12.1 Beta (21C5039b)
• m1 Apple Silicon

Random other ideas

• Link blog post from readme
• Uninstall guides :)

[BirkhoffLee]

hi frank - thank you for reporting the issue, i have updated README accordingly. could you provide:

• output of ls -l /Library/LaunchDaemons/me.birkhoff.persistent_pam_tid.plist after system upgrade
• output of ls -l /usr/local/bin/pam-tid-installer after system upgrade

[BirkhoffLee]

and check these two log files /tmp/pam-tid-installer.stdout.log /tmp/pam-tid-installer.stderr.log as well

[frank-laemmer]

Will do with the next update. I am under the impression that this also happens after restart / reboot (not system update).

[frank-laemmer]

I have some trouble re-producing the issue currently. It seems to survive restart, which was not the case before, as far as I recall. I plan to test with next macOS software update.

[frank-laemmer]

After system upgrade macOS 12.1 (21C51):

ls -l /Library/LaunchDaemons/me.birkhoff.persistent_pam_tid.plist
-rw-r--r--  1 root  wheel  672 Dec  7 20:09 /Library/LaunchDaemons/me.birkhoff.persistent_pam_tid.plist

ls -l /usr/local/bin/pam-tid-installer
-rwxr-xr-x  1 root  admin  282 Dec  7 20:09 /usr/local/bin/pam-tid-installer

/tmp/pam-tid-installer.stdout.log seems to be empty.
/tmp/pam-tid-installer.stderr.log has this:

sed: /etc/pam.d/sudo: Operation not permitted
sed: /etc/pam.d/sudo: Operation not permitted

Then I re-installed the persistent-pam-tid tool.

The line auth sufficient pam_tid.so in /etc/pam.d/sudo is still missing. I added the line manually (if I understand the tool correctly, it will only add the line during startup not by installing).

I restarted the computer. sudo via touch ID is still possible. Not sure if that is standard behavior or because of this tool. I am under the impression, that even after restart (not software update) the Touch ID sudo was gone.

Thanks for creating the tool one more time!

[BirkhoffLee]

My best guess is that macOS Monterey has introduced new changes that breaks the standard way of modifying /etc/pam.d/sudo, or there's a change to LaunchDaemon. I'll need to upgrade my Macbook to actually test out what;s going on, and I'll give you an update on this issue thereafter.

[BirkhoffLee]

So apparently the kernel is preventing sed from modifying /etc/pam.d/sudo. I don't get how it get sandboxed (I'm not a specialist at macOS though):
System Policy: sed(10825) deny(1) file-write-create /private/etc/pam.d/.!10825!sudo

Update: it's TCC that is blocking write access to the file:

...
21-12-14 20:03:40.555 TCC         REQUEST: tccd_uid=0, sender_pid=150, sender_uid=0, sender_auid=-1, function=TCCAccessRequest, msgID=150.150
21-12-14 20:03:40.555 TCC         REQUEST_MSG: msgID=150.150, msg={
	service="kTCCServiceSystemPolicySysAdminFiles"
	TCCD_MSG_SPI_VERSION=2 (0x2)
	user_tccd_unavailable=true
	function="TCCAccessRequest"
	TCCD_MSG_MESSAGE_OPTION_REQUEST_RECORD_UPGRADE_POLICY_POLICY_KEY=1 (0x1)
	TCCD_MSG_REQUEST_TYPE_KEY=0 (0x0)
	TCCD_MSG_MESSAGE_OPTION_REQUEST_PROMPT_RIGHTS_MASK_KEY=5 (0x5)
	TCC_MSG_REQUEST_AUTHORIZATION_SUBJECT_CREDENTIAL_DICTIONARY_KEY={
		TCCD_MSG_CREDENTIAL_AUTHENTICATOR_TYPE_KEY=1 (0x1)
		TCCD_MSG_CREDENTIAL_AUTHENTICATOR_AUDIT_TOKEN_KEY={pid:69241, auid:-1, euid:0}
	}
	TCCD_MSG_MESSAGE_OPTION_REQUEST_USAGE_STRING_POLICY_KEY=2 (0x2)
	TCCD_MSG_MESSAGE_OPTION_REQUEST_PROMPT_POLICY_KEY=2 (0x2)
	TCCD_MSG_ID="150.150"
}
21-12-14 20:03:40.555 TCC         Constructed 'accessingProcess' from indirect_object_token in message from <TCCDProcess: identifier=com.apple.sandboxd, pid=150, auid=0, euid=0, binary_path=/usr/libexec/sandboxd>
21-12-14 20:03:40.555 TCC         AttributionChain: responsible={<TCCDProcess: identifier=com.apple.bash, pid=69218, auid=0, euid=0, responsible_path=/bin/bash, binary_path=/bin/bash>}, accessing={<TCCDProcess: identifier=com.apple.sed, pid=69241, auid=0, euid=0, binary_path=/usr/bin/sed>}, requesting={<TCCDProcess: identifier=com.apple.sandboxd, pid=150, auid=0, euid=0, binary_path=/usr/libexec/sandboxd>},
21-12-14 20:03:40.556 TCC         per-user tccd is unavailable; handling in system tccd; service: kTCCServiceSystemPolicySysAdminFiles
21-12-14 20:03:40.556 TCC         handle_TCCAccessRequest: incoming client: 150, for: <private>
21-12-14 20:03:40.556 TCC         Constructed 'accessingProcess' from indirect_object_token in message from <TCCDProcess: identifier=com.apple.sandboxd, pid=150, auid=0, euid=0, binary_path=/usr/libexec/sandboxd>
21-12-14 20:03:40.556 TCC         AttributionChain: responsible={<TCCDProcess: identifier=com.apple.bash, pid=69218, auid=0, euid=0, responsible_path=/bin/bash, binary_path=/bin/bash>}, accessing={<TCCDProcess: identifier=com.apple.sed, pid=69241, auid=0, euid=0, binary_path=/usr/bin/sed>}, requesting={<TCCDProcess: identifier=com.apple.sandboxd, pid=150, auid=0, euid=0, binary_path=/usr/libexec/sandboxd>},
21-12-14 20:03:40.556 TCC         AUTHREQ_CTX: msgID=150.150, function=TCCAccessRequest, service=kTCCServiceSystemPolicySysAdminFiles, preflight=yes, query=1,
21-12-14 20:03:40.556 TCC         AUTHREQ_ATTRIBUTION: msgID=150.150, attribution={responsible={<TCCDProcess: identifier=com.apple.bash, pid=69218, auid=0, euid=0, responsible_path=/bin/bash, binary_path=/bin/bash>}, accessing={<TCCDProcess: identifier=com.apple.sed, pid=69241, auid=0, euid=0, binary_path=/usr/bin/sed>}, requesting={<TCCDProcess: identifier=com.apple.sandboxd, pid=150, auid=0, euid=0, binary_path=/usr/libexec/sandboxd>}, },
21-12-14 20:03:40.557 TCC         IDENTITY_ATTRIBUTION: /bin/bash[150]: from cache: = /bin/bash, type 1 (367/536)
21-12-14 20:03:40.557 TCC         AUTHREQ_SUBJECT: msgID=150.150, subject=/bin/bash,
21-12-14 20:03:40.557 TCC         Refusing TCCAccessRequest for service kTCCServiceSystemPolicySysAdminFiles from client Sub:{/bin/bash}Resp:{<TCCDProcess: identifier=com.apple.bash, pid=69218, auid=0, euid=0, responsible_path=/bin/bash, binary_path=/bin/bash>} in background session
21-12-14 20:03:40.557 TCC         AUTHREQ_RESULT: msgID=150.150, authValue=0, authReason=5, authVersion=1, error=(null),
21-12-14 20:03:40.557 TCC         REPLY_MSG: msg={
	auth_value=0 (0x0)
	result=false
	auth_version=1 (0x1)
	auth_reason=5 (0x5)
}
21-12-14 20:03:40.557 TCC         REPLY: (0) function=TCCAccessRequest, msgID=150.150
21-12-14 20:03:40.557 TCC         RECV: synchronous reply <dictionary: 0x7f8c3d010490> { count = 4, transaction: 0, voucher = 0x0, contents =
	"auth_value" => <uint64: 0x7d002119dab45367>: 0
	"result" => <bool: 0x7ff8552e21a0>: false
	"auth_version" => <uint64: 0x7d002119dab44367>: 1
	"auth_reason" => <uint64: 0x7d002119dab40367>: 5
}
21-12-14 20:03:40.558 sandbox     disposing: 0x7f8c3d014dd0(OS_tcc_authorization_record)
21-12-14 20:03:40.558 sandbox     disposing: 0x7f8c3d207fd0(OS_tcc_message_options)
21-12-14 20:03:40.558 sandbox     disposing: 0x7f8c3d208430(OS_tcc_credential)
21-12-14 20:03:40.558 sandbox     kTCCServiceSystemPolicySysAdminFiles denied by TCC for sed
21-12-14 20:03:40.558 kernel      sandboxd rejected approval request from sed for kTCCServiceSystemPolicySysAdminFiles (/private/etc/pam.d/.!69241!sudo): denied

[frank-laemmer]

Thanks for the updates. That correlates with my observations. sudo mode removed after simple restart again.

On the other side, a fingerprint is pretty easy to fork and probably not as secure as a secure password. But having a secure sudo password is also a hustle when to be typed often. Hm.

[BirkhoffLee]

Yes, after some investigation it seems Apple has restricted access to /etc/pam.d/sudo in TCC on macOS Monterey, I have currently no idea how this could be fixed :(

[rluvaton]

Wanted to use this tool and saw this issue, is this only for sed?

I have an ansible playbook to setup my dev machine and in there I add the pam_tid.so to /etc/pam.d/sudo if missing, and it's working (until now I tested it only in a VM...)

I have M1 Max if interested and Monterey (the VM is also Monterey)...

[rluvaton]

After debugging and trying to solve this for the past 4 hours and I found something that may help but I couldn't apply it to our case - macOS processes — What to do when your daemon gets blocked by permissions dialogues.

The problem I found out is that like it says in the article, we run it as root and there is no GUI session* so the user is not prompt for the TCC GUI, even when I tried to add the binary to the Full Disk Access in the privacy settings it didn't work.

if someone want to try to solve this I think the linked link below is the best option we have

A possible solution is to add the /usr/local/bin/pam-tid-installer file to the files that run on startup and add before any sed - sudo

---

I've also tried to set suid to the file so any user can run it as root (and I limited write access to root only) but it didn't work either...

And also I've tried to change the file /etc/pam.d/sudo using Swift but I couldn't gain permission either (I don't really know Swift)