How can I have a non-elevated script execute another specific script as root without requiring a password from the user?

Question

I have a script, let's call it on-event.sh, that's going to be run at specific times, such as when a particular application launches or quits. The script itself will run as the current user (not root) since I'll be using BetterTouchTool to execute it.

However, on-event.sh needs to somehow trigger the execution of another script that must run as root, which I'll call run-as-root.sh. run-as-root.sh will execute some commands to load or unload specific third party launch daemons (not my own), hence the need to run as root. Since it'll all be happening in the background, it needs to happen without requiring user intervention, so it can't use sudo or AppleScript's with administrator privileges. Because of the obvious security implications, I only want it to be possible to execute run-as-root.sh as root and not any arbitrary script or terminal command.

One option I'm already aware of is I could create a launch daemon that opens a socket, waits for a connection, and then executes run-as-root.sh, and have on-event.sh connect to that socket. But that's a more heavy weight solution and I'm hoping for an easier way to do this.

How can I set it up so this is possible?

Answer 1

You can use sudo to allow a user to run specific commands as root, without the need for a password.

To allow user bribri to run launchctl, run sudo visudo -f /etc/sudoers.d/launchctl and add

bribri ALL = (root) NOPASSWD: /bin/launchctl

then save and exit. Afterwards, the user can run

sudo launchctl ...

without getting prompted for a password.

The caveat here is that this gives the user the rights to start/stop/load/unload any LaunchAgents/Daemons. To avoid this, a shell script could be used to wrap the launchctl call, but this brings a bunch of security risks. To at least reduce them

• put the script into a dedicated directory,
• make sure both the directory and the script are owned by root and chmoded to 0700,
• keep the script as short as possible (include only things which must be run as root),
• use absolute paths for all commands called in the script,
• avoid to rely on any environment variables.

Answer 2

You can write a simple program which will run the run-as-root.sh script as root. For example, there is the C program shown below.

% cat run-as-root.c
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
int main() {
    setuid(0);
    system("./run-as-root.sh");
    return 0;
}

I have command line developer tools installed, so I can enter the following to create the executable run-as-root, which will run as the root user.

% sudo rm -f run-as-root
% gcc run-as-root.c -o run-as-root
% sudo chown root run-as-root
% sudo chmod u+s run-as-root   

Below are sample on-event.sh and run-as-root.sh scripts. Also the file permissions and owners are shown.

% cat on-event.sh
echo "I am on-event.sh and my user id is $(id -u)"
./run-as-root
%
% cat run-as-root.sh
echo "I am run-as-root.sh and my user id is $(id -u)"
%
% chmod +x on-event.sh run-as-root.sh
% ls -l run-as-root on-event.sh run-as-root.sh
-rwxr-xr-x@ 1 davidanderson  staff     14 Apr 30 13:04 on-event.sh
-rwsr-xr-x  1 root           staff  49472 Apr 30 13:24 run-as-root
-rwxr-xr-x@ 1 davidanderson  staff     30 Apr 30 13:26 run-as-root.sh

Running the on-event script results in the run-as-root.sh script executing as root user. (The root user has user id of 0.)

% ./on-event.sh
I am on-event.sh and my user id is 501
I am run-as-root.sh and my user id is 0

Answer 3

If your issue is file permissions; macOS, like all its unixen siblings, supports the "setuid" and "setgid" bits on files. (And the sticky bit on directories via the same model, but that is out of scope for this answer.) Per Wikipedia's article on setuid:

The Unix and Linux access rights flags setuid and setgid (short for set user identity and set group identity) allow users to run an executable with the file system permissions of the executable's owner or group respectively and to change behaviour in directories. They are often used to allow users on a computer system to run programs with temporarily elevated privileges to perform a specific task. While the assumed user id or group id privileges provided are not always elevated, at a minimum they are specific.

A file can be chmoded 4755, and when run by any user, it will inherit the file system permissions of the user that owns the file. Note that if you chown a file, it drops any of the setuid/setgid/sticky bits, so chown first, chmod second.

If your issue is elevated execution authorization, nohillside's answer about setting up sudo appropriately is more relevant.

See also: A detailed explanation of setuid in a unix.se answer