[Feature Request]: Allow running Herd on restricted user accounts

[SebHanke]

Operating system version

macOS Sonoma 14.0

System architecture

ARM64 (M1, M2, etc)

Herd Version

1.3.1

PHP Version

PHP 8.2

Bug description

I have installed herd.
FPM 8.2 runs.

But nginx and dnsmasq wont start.
Logfile says for both: "sudo: a terminal is required to read the password; either use the -S option to read form standard input or configure an askpass helper"

What can i do to start the complete environment?

Steps to reproduce

No response

Relevant log output

No response

[decnorton]

We're having a similar issue when trying to run herd from a non-sudoers account. Our organisation has a requirement where day-to-day activities (i.e. web, email) must be carried out on a non-admin account. Developers can have an admin account, but must use it sparingly and not use it by default.

Installing from a non-admin account was promising: prompted for an admin username and password. When it came to running the services, the same problem occurred as above happened when trying to start the services; only affecting nginx and dnsmasq.

Ideally, we'd like to be prompted for a sudo username and password when starting the services (if sudo is required).

[thynus]

Same problem nginx won't start logged into my standard account. Works when logged in as admin.
Macbook Pro Intel macOS 12.7.1

[yocmen]

The same thing is happening to me, if the account is not an admin account you get that error in the logs

[xartuu]

I come with the same problem. The installation was successful while as a normal user you can't enable nginx, dnsmasq or php-fpm services. A super option would be to add a window to ask for the administrator password for those without privileges, as is the case during installation. Featured image:

[mpociot]

Herd cheaters a sudoers file in /etc/sudoers.d/herd

We usually target the "admin" group which by default every Mac user belongs to.
Could you check if your user is in that same group as well?

[xartuu]

For security reasons, I decided to use a separate admin account with sudo permissions to avoid sudo abuse from different applications. The user I use on a daily basis is not in the admin or sudo group and I wouldn't want him to be.

That's why I'm thinking about how cool it would be if Herd would ask for additional permissions via the admin login window when a user doesn't have enough permissions. Many users like me would be delighted with such a function.

[shackep]

I am in a similar boat as some of the others here. I am on a locked down corporate laptop. I do have sudo access, but any sudo interactions have to be prompted, but I don't get a change to provide one in herd. I am not able to start Nginx, DNSMasq or FPM.

[robertspektor]

Same issue here :/

[xartuu]

Any updates here?

[sschlein]

We've identified the problem and have a rough idea for a solution but don't know when this will be implemented

[decnorton]

We've identified the problem and have a rough idea for a solution but don't know when this will be implemented

Great that you've managed to identify it. Are you able to share details so that we may look for a potential workaround?

Separation of privileged and non-privileged accounts is a pain for us to manage as an organisation. If this could be addressed, we'd have no hesitation in purchasing Herd Pro for all of our developers.

[mpociot]

I don't think there's a workaround.
We are currently relying on the sudoers file entry and therefore execute root services, such as dnsmasq or nginx, via sudo.
We would need to modify it so that we manually check if a user is actually in the sudoers group/file or not and ask for a password if that's not the case.

I assume in your setup, the sudoers file exists, but it got written for a different user. We basically allow the herd commands for everyone in the %admin group, which your user is not a part of.

[sschlein]

I have made this a feature request as it's not a bug. The plan is to promt for every interaction that needs admin permissions if the use of the sudoers file fails.

[jorks]

Rather than using the sudoers configuration, this can be achieved with a Privileged Helper Tool to allow an app to launch services with root permissions using secure XPC calls.

For reference, Mist is an open-source Swift App that implements a Privileged Helper Tool using Blessed and SecureXPC to support the Privileged Helper Tool.

I hope this is useful - I also work in an organisation where admin/sudo access is gated behind an escalation tool. After uninstalling my Laravel brew/valet environment, I discovered that Herd doesn't work even after escalating my account (due to our escalation tool editing the sudoers file). 😭

[xartuu]

There's been a bit of a buzz around here, so I'd like to ask if you're already working on a solution and if you have a specific implementation date?

[jorks]

I found a workaround if you can elevate to Admin temporarily and edit Herd-created sudoers file, or ask your MDM admins to run a script to achieve the same outcome:

1. Quit Herd and elevate to Admin
2. Edit the Herd-created sudo file sudo visudo /etc/sudoers.d/herd
3. Using VIM, replace the word %admin with your account shortname (eg bobsmith) and save
4. Demote your account back to a standard account (non-admin), launch Herd and the services should start
5. You may require a reboot if there are services already bound to ports/sockets.

This is a hack so you're on your own for support and I can't guarantee this will survive Herd updates - but it works for me until there is official support for non-Admin accounts :)

[gtmassey]

This works fantastically for DNSmasq and FPM, but it seems that if you try to use this approach and also try to secure a site over HTTPS, nginx complains that it can't find the .cert file. Any thoughts on how to resolve this?

2024/05/01 13:52:18 [emerg] 4304#40433: cannot load certificate "/Users/gtmassey/Library/Application Support/Herd/config/valet/Certificates/mysite.test.crt": BIO_new_file() failed (SSL: error:80000002:system library::No such file or directory:calling fopen(/Users/gtmassey/Library/Application Support/Herd/config/valet/Certificates/mysite.test.crt, r) error:10000080:BIO routines::no such file)

This is the nginx log. This is also a fresh install of herd on a brand new MacBook Pro, and I followed the steps you outlined @jorks. PHP is running, FPM is running, dnsmasq is running, but nginx won't run, and I can't unsecure the site now that I've tried to secure it either.

[ReArmedHalo]

I haven't gotten SSL working (I can't even activate SSL), but I wrote this script to use as a "postinstall" process when Herd is deployed via Jamf for my company users. Herd thinks the first launch install has completed so users do have to manually install PHP and select PHP (otherwise the necessary .sock files in ~/Application Support/Herd aren't created) but that's something I'm fine with for now.

I'm still testing of course, not sure if we will ultimately use Herd or Sail. I'm really liking Herd though, less configuration and having dnsmasq is great! I have scripts for Valet if anyone is interested. I'm trying to not need brew on endpoints, so Herd seems perfect! Hopefully this can be properly resolved in the future.

#!/bin/bash

loggedInUser=$( scutil <<< "show State:/Users/ConsoleUser" | awk '/Name :/ && ! /loginwindow/ { print $3 }' )

helper="/Applications/Herd.app/Contents/Library/LaunchServices/de.beyondco.herd.helper"
cp $helper /Library/PrivilegedHelperTools

mkdir /etc/sudoers.d
echo "$loggedInUser ALL=(root) NOPASSWD:SETENV: /usr/bin/security" > /etc/sudoers.d/herd
mkdir /etc/resolver
echo "nameserver 127.0.0.1" > /etc/resolver/test

chown root:wheel $helper
chown -R root:wheel /etc/resolver
chown -R root:wheel /etc/sudoers.d

[binteso]

I'm using Herd on a mac which is under my full controll. None the less I got an error for nginx and dnsmasq all the time.
Workaround I figured out was to add my user to the sudoers file manually. This did not work at the beginning and I had to change the sudoers file (/private/etc/sudoers.d/sudoers) manually to
<username> ALL=(ALL) NOPASSWD: ALL
It only worked after I have given me the NOPASSWD right explicitly.
This has cost me ~3 hours to figure it out - hope it helps somebody with the same issue. And my upvote for a change to a better permission handling