Service does not work after upgrade #8

stackptr · 2022-02-16T19:06:14Z

This worked for me until some point recently, possibly due to an OS upgrade. I upgraded the package to see if that would fix things:

❯ brew install artginzburg/tap/sudo-touchid

Running `brew update --preinstall`...
==> Auto-updated Homebrew!
Updated 3 taps (homebrew/core, homebrew/cask and homebrew/services).
<snip>

sudo-touchid 0.2 is already installed but outdated (so it will be upgraded).
==> Downloading https://github.com/artginzburg/sudo-touchid/releases/download/0.3/sudo-touchid.sh
==> Downloading from https://objects.githubusercontent.com/github-production-release-asset-2e65be/389117398/ee
######################################################################## 100.0%
==> Upgrading artginzburg/tap/sudo-touchid
  0.2 -> 0.3 

==> Caveats
To restart artginzburg/tap/sudo-touchid after an upgrade:
  sudo brew services restart artginzburg/tap/sudo-touchid
Or, if you don't want/need a background service you can just run:
  /opt/homebrew/opt/sudo-touchid/bin/sudo-touchid
==> Summary
🍺  /opt/homebrew/Cellar/sudo-touchid/0.3: 5 files, 4.5KB, built in 1 second
==> Running `brew cleanup sudo-touchid`...
Disable this behaviour by setting HOMEBREW_NO_INSTALL_CLEANUP.
Hide these hints with HOMEBREW_NO_ENV_HINTS (see `man brew`).
Removing: /opt/homebrew/Cellar/sudo-touchid/0.2... (5 files, 3.4KB)
Warning: Directory not empty @ dir_s_rmdir - /opt/homebrew/Cellar/sudo-touchid/0.2

❯ sudo brew services start sudo-touchid

Password:
Warning: Taking root:admin ownership of some sudo-touchid paths:
  /opt/homebrew/Cellar/sudo-touchid/0.3/bin
  /opt/homebrew/Cellar/sudo-touchid/0.3/bin/sudo-touchid
  /opt/homebrew/opt/sudo-touchid
  /opt/homebrew/opt/sudo-touchid/bin
  /opt/homebrew/var/homebrew/linked/sudo-touchid
This will require manual removal of these paths using `sudo rm` on
brew upgrade/reinstall/uninstall.
/Library/LaunchDaemons/homebrew.mxcl.sudo-touchid.plist: service already bootstrapped
Bootstrap failed: 37: Operation already in progress
Error: Failure while executing; `/bin/launchctl bootstrap system /Library/LaunchDaemons/homebrew.mxcl.sudo-touchid.plist` exited with 37.

❯ sudo brew services stop sudo-touchid

Stopping `sudo-touchid`... (might take a while)
==> Successfully stopped `sudo-touchid` (label: homebrew.mxcl.sudo-touchid)

❯ sudo brew services start sudo-touchid
Warning: Taking root:admin ownership of some sudo-touchid paths:
  /opt/homebrew/Cellar/sudo-touchid/0.3/bin
  /opt/homebrew/Cellar/sudo-touchid/0.3/bin/sudo-touchid
  /opt/homebrew/opt/sudo-touchid
  /opt/homebrew/opt/sudo-touchid/bin
  /opt/homebrew/var/homebrew/linked/sudo-touchid
This will require manual removal of these paths using `sudo rm` on
brew upgrade/reinstall/uninstall.
==> Successfully started `sudo-touchid` (label: homebrew.mxcl.sudo-touchid)

After the above, sudo still requires my password. It appears the script has not changed the files in the expected ways:

❯ cat /etc/pam.d/sudo
# sudo: auth account password session
auth       sufficient     pam_smartcard.so
auth       required       pam_opendirectory.so
account    required       pam_permit.so
password   required       pam_deny.so
session    required       pam_permit.so

❯ cat /etc/pam.d/sudo.bak
2022/02/16 11:03:31 open /etc/pam.d/sudo.bak: no such file or directory

I tried uninstalling via brew (requiring manually removing /opt/homebrew/Cellar/sudo-touchid/{0.2,0.3}) but it's the same result.

Manually running /opt/homebrew/opt/sudo-touchid/bin/sudo-touchid fixes the issue.

The text was updated successfully, but these errors were encountered:

artginzburg · 2022-02-17T15:34:35Z

To be clear, running sudo brew services start sudo-touchid just creates a daemon that runs sudo-touchid automatically on system start. So after a macOS upgrade, sudo can be used with TouchID again. The daemon also runs sudo-touchid right when it's started, so that the user doesn't have to restart macOS or run the command manually when we already know that the user's intention is to enable TouchID for sudo

What I'm not sure about is whether you're still experiencing the issue. If manually running sudo-touchid fixes the issue, but as we already know the service simply runs it automatically, does it mean that your issue is only related to the service itself? And if so, do any other brew services work after your OS upgrade?

stackptr · 2022-02-27T20:57:28Z

What I'm not sure about is whether you're still experiencing the issue. If manually running sudo-touchid fixes the issue, but as we already know the service simply runs it automatically, does it mean that your issue is only related to the service itself? And if so, do any other brew services work after your OS upgrade?

This is the only service I use through brew, so unfortunately I cannot isolate this as being an issue with the particular service or some broader issue in background services.

I updated recently to 12.2.1 and saw that sudo had again reverted to requiring text entry. sudo-touchid is still listed as a background service:

❯ brew services
Name         Status User File
sudo-touchid none   root 
unbound      none

I again ran the command manually:

❯ /opt/homebrew/opt/sudo-touchid/bin/sudo-touchid
Password:
Created a backup file at /etc/pam.d/sudo.bak

... And this has restored the expected behavior.

stackptr · 2022-02-27T21:05:03Z

I see that com.user.sudo-touchid.plist defines a ProgramArguments invoking /usr/local/bin/sudo-touchid. I believe this fails on Apple Silicon because homebrew installs packages to a default prefix of /opt/homebrew. Therefore, resolving this issue entails writing a different value to this plist based on brew --prefix.

stackptr · 2022-02-27T21:53:58Z

Actually it seems like like the relevant plist would be generated in the formula, which is:

❯ cat /Library/LaunchDaemons/homebrew.mxcl.sudo-touchid.plist 
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>Label</key>
	<string>homebrew.mxcl.sudo-touchid</string>
	<key>ProgramArguments</key>
	<array>
		<string>/opt/homebrew/opt/sudo-touchid/bin/sudo-touchid</string>
	</array>
	<key>RunAtLoad</key>
	<true/>
</dict>
</plist>

That path is valid and points version 0.3 of this script.

artginzburg · 2022-05-14T12:04:54Z

@stackptr how is it going? I'm just interested whether the issue is resolved by Homebrew or we need to change something in the formula.

jrmann100 · 2022-09-12T14:36:36Z

@artginzburg, was this ever resolved? I am getting the same issue.

artginzburg · 2022-09-12T15:54:05Z

@jrmann100 not sure I get what's the issue. Is it that the launch daemon does not run the command right when it is started, but only at system load?

jrmann100 · 2022-09-12T15:58:10Z

It seems like my launch daemon was disabled after a macOS upgrade. It seems to have been re-bootstrapped after I manually ran the script as suggested above.

jrmann100 · 2022-09-12T15:59:06Z

Hard to isolate the situation though, will open a new issue if it happens again and let this one rest.

artginzburg · 2022-09-12T16:08:01Z

Just now realised I have the same issue. sudo brew services list gives status "stopped" for sudo-touchid, and I did not stop it. I'm assuming a macOS upgrade happened at weekends, but not sure entirely.

Maybe launch daemons are automatically stopped on system upgrade now. Or maybe it's Homebrew's logic. Need to check.

UPD: I think "stopped" as a status does not mean that the service is not active, but rather means that the specified command was executed and is not running right now. Which is expected since the command is not active, it just runs and quits. But I can confirm that sudo-touchid did not automatically run in my case.

newadventure079 · 2022-10-24T20:29:05Z

Mine isn't working after an upgrade either.

I've done multiple OS upgrades thru some of the Ventura betas and each time sudo -v prompts for my password. I then have to run sudo-touchid and then it says it made changes to the file and then after that the touchID prompt will happen

newadventure079 · 2022-11-11T05:28:50Z

I upgraded to 13.0.1 and sudo-touchid was not loaded and working. I had to manually run sudo-touchid and type in my password. Then I ran it again just for fun and it said [TouchID for sudo] seems to be enabled already

artginzburg · 2023-01-03T02:47:00Z

Tried the following property list on macOS Ventura. It was successful in executing sudo-touchid, but sudo-touchid then failed to execute the sed command. So, no luck yet.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>Label</key>
	<string>org.artginzburg.sudoTouchIDDaemon</string>
	<key>MachServices</key>
	<dict>
		<key>org.artginzburg.sudoTouchIDDaemon</key>
		<true/>
	</dict>
	<key>Program</key>
	<string>/opt/homebrew/bin/sudo-touchid</string>
	<key>ProgramArguments</key>
	<array>
		<string>/opt/homebrew/bin/sudo-touchid</string>
	</array>
</dict>
</plist>

If anyone wants to try the same, here are the steps:

I wrote the file to /Library/LaunchDaemons/org.artginzburg.sudoTouchIDDaemon.plist
Changed its owner to system so that the next command can execute: sudo chown root /Library/LaunchDaemons/org.artginzburg.sudoTouchIDDaemon.plist
Loaded the service: sudo launchctl load /Library/LaunchDaemons/org.artginzburg.sudoTouchIDDaemon.plist
Enabled logging output to a file for the next run: sudo launchctl debug system/org.artginzburg.sudoTouchIDDaemon --stdout ~/Desktop/test-sudo-touchid.txt
Forced the service to start: sudo launchctl kickstart system/org.artginzburg.sudoTouchIDDaemon

The output in the file was: [TouchID for sudo] failed to execute. Which is programmed to be output if the sed command fails to insert touch pam into sudo auth config. I tried logging what the sed command actually outputs to locate the problem, but failed to do so — the output file was just empty. Looks like I missed something important.

artginzburg · 2023-02-06T12:36:40Z

I tried outputting errors to a file by specifying service.error_log_path in the formula, installing it, and starting the service.

The error in the file was quite confusing:

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

I tried explicitly giving Write permissions to the wheel user, as that's the user seen in homebrew services list; that did not change anything about the error.

So, I'm guessing that macOS in the last versions prohibits any attempts to programmatically change the system files, even if the attempting script has root privileges. In other words, it seems to only allow changes directly initiated by the user. Which sounds great for safety reasons, and resembles e.g. Safari's behavior (every API that interacts with the system outside the very content of the page the user is on seems to only work via direct user initiative, like a click event). But well, would be good if there was a way to disable this protection.

artginzburg · 2023-02-06T12:52:35Z

Meanwhile, considering the message above, I propose the following:

We could make a new script store the current system version. Then it will run without root privileges on system startup and check the current major version. If it's different from the stored one, it will run open $(which sudo-touchid), which will open Terminal asking for a password and executing sudo-touchid.

This is far from automatic, but sounds like the simplest solution for now.

imgrant · 2023-04-26T11:52:56Z

I tried outputting errors to a file by specifying service.error_log_path in the formula, installing it, and starting the service.

The error in the file was quite confusing:
sed: /etc/pam.d/sudo: Operation not permitted
I tried explicitly giving Write permissions to the wheel user, as that's the user seen in homebrew services list; that did not change anything about the error.

So, I'm guessing that macOS in the last versions prohibits any attempts to programmatically change the system files, even if the attempting script has root privileges. In other words, it seems to only allow changes directly initiated by the user. Which sounds great for safety reasons, and resembles e.g. Safari's behavior (every API that interacts with the system outside the very content of the page the user is on seems to only work via direct user initiative, like a click event). But well, would be good if there was a way to disable this protection.

One solution to this is to grant Full Disk Access permission in macOS to /bin/bash — I tried this and then the LaunchAgent was able to fix the PAM file.
Because sudo-touchid is a (Bash) shell script, granting Full Disk Access to /opt/homebrew/opt/sudo-touchid/bin/sudo-touchid isn't sufficient.

A better solution than granting Full Disk Access to anything via Bash might be to create a binary instead; I followed the lead of a similar post on Stack Overflow and used this C code:

#include <stdlib.h>
int main(void) {
  int status = system("/opt/homebrew/opt/sudo-touchid/bin/sudo-touchid");
  int ret = WEXITSTATUS(status);
  return ret;
}

Compiled with gcc -Wall -o sudo-touchid-wrapper sudo-touchid-wrapper.c, and then edited the LaunchAgent to use this binary instead. When first run, it appears in macOS System Settings > Privacy & Security > Full Disk Access; when toggled to on the LaunchAgent can successfully edit /etc/pam.d/sudo.

artginzburg · 2023-04-26T12:18:19Z

@imgrant thanks, this is huge! I'll check it out in depth when I can

newadventure079 · 2023-04-26T17:59:20Z

I had actually already enabled Full Disk Access previously to /bin/bash and still see the issue

imgrant · 2023-04-26T18:10:58Z

I had actually already enabled Full Disk Access previously to /bin/bash and still see the issue

Hmm. 🤷 Did you try the binary wrapper approach?

newadventure079 · 2023-04-26T18:14:10Z

No, not yet. I was just stating that I've had already given /bin/bash Full Disk Access because of other homebrew and personal scripts in the past

artginzburg closed this as completed Aug 8, 2022

artginzburg reopened this Sep 12, 2022

artginzburg mentioned this issue Jan 2, 2023

Running Homebrew as root is extremely dangerous and no longer supported. #12

Open

artginzburg added bug Something isn't working help wanted Extra attention is needed labels Jan 2, 2023

artginzburg mentioned this issue Jan 3, 2023

podman service fails to start on macOS Homebrew/homebrew-core#118717

Closed

2 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Service does not work after upgrade #8

Service does not work after upgrade #8

stackptr commented Feb 16, 2022

artginzburg commented Feb 17, 2022 •

edited

Loading

stackptr commented Feb 27, 2022

stackptr commented Feb 27, 2022 •

edited

Loading

stackptr commented Feb 27, 2022

artginzburg commented May 14, 2022

jrmann100 commented Sep 12, 2022

artginzburg commented Sep 12, 2022

jrmann100 commented Sep 12, 2022

jrmann100 commented Sep 12, 2022

artginzburg commented Sep 12, 2022 •

edited

Loading

newadventure079 commented Oct 24, 2022

newadventure079 commented Nov 11, 2022

artginzburg commented Jan 3, 2023

artginzburg commented Feb 6, 2023

artginzburg commented Feb 6, 2023

imgrant commented Apr 26, 2023

artginzburg commented Apr 26, 2023

newadventure079 commented Apr 26, 2023

imgrant commented Apr 26, 2023

newadventure079 commented Apr 26, 2023

Service does not work after upgrade #8

Service does not work after upgrade #8

Comments

stackptr commented Feb 16, 2022

artginzburg commented Feb 17, 2022 • edited Loading

stackptr commented Feb 27, 2022

stackptr commented Feb 27, 2022 • edited Loading

stackptr commented Feb 27, 2022

artginzburg commented May 14, 2022

jrmann100 commented Sep 12, 2022

artginzburg commented Sep 12, 2022

jrmann100 commented Sep 12, 2022

jrmann100 commented Sep 12, 2022

artginzburg commented Sep 12, 2022 • edited Loading

newadventure079 commented Oct 24, 2022

newadventure079 commented Nov 11, 2022

artginzburg commented Jan 3, 2023

artginzburg commented Feb 6, 2023

artginzburg commented Feb 6, 2023

imgrant commented Apr 26, 2023

artginzburg commented Apr 26, 2023

newadventure079 commented Apr 26, 2023

imgrant commented Apr 26, 2023

newadventure079 commented Apr 26, 2023

artginzburg commented Feb 17, 2022 •

edited

Loading

stackptr commented Feb 27, 2022 •

edited

Loading

artginzburg commented Sep 12, 2022 •

edited

Loading