Display Script in Terminal to User and Run as Root

[joelsenders]

Hey Folks,

Having some trouble. I have need to run a bash script (or command file) so that it opens and displays to the user and is interactive. The user gives input and sees information, so the jamf binary can't run it silently. However, the script they are interacting with uses some commands that require root access (jamf, for example). I want the script to open with root privileges. I figured having the Jamf binary launch the script would do this, effectively acting as a wrapper and granting root access since it is launching the script. I did this by packaging the script, placing it in a policy, and then attaching a post script to the policy to "open" the command file. The policy is then run in self service which silently installs the script file and then opens it. It seemed to be working for a bit, but I added a jamf command to it now and it says it must be run as root. I don't want to prompt the user for their password, I just want the whole script run as root. Is this possible?

As a fallback option, is there an elegant way of asking for an admin user's credentials at the beginning of the script (different than the GUI logged in user) and then using those creds later on as sudo is needed?

Any help would be greatly appreciated.

[sshort]

The pkg wrapper seems like an extraneous step, just stick the script in a self service policy, and that will run as root. You can add user interactive prompts with osascript and have any specific command run as the current logged in user if needed. Here's an example I made that uses a self service policy to sync a user's mismatched password, and displays prompts to the user as needed: https://github.com/ducksrfr/mac_admin/blob/master/scripts/Mojave_FileVault_Sync.sh

[joshuasee]

You can have SS open Terminal as root with Files and Processes | Execute Command, and have it run a script by giving that as a command line argument, but it is not a good idea. In particular, if the user spawns another Terminal window, they get a root prompt to use as they will. I would follow sshort's advice and use osascript for interactivity on a script run from inside a policy, not Terminal.

[tlarkin]

Maybe use a PKG to lay the script down and then use the open command to open it in terminal, however, I bet TCC will hate this, and trying to open a .command file as root in user space is probably going to be pretty tricky.

Then you can use whatever language you want, I have an example until loop script I wrote for training purposes years ago, here it is:

#!/bin/bash

# poc script to automatically open an interactive terminal shell, this is a POC no warranty given

selection=
until [[ "${selection}" == 0 ]] ; do
  echo ""
  echo "Select an option"
  echo "1 - Do a barrel roll"
  echo "2 - Do the Bartman"
  echo "3 - Do or do not, there is no try"
  echo "0 - Enter 0 to exit..."
  echo ""
  echo -n "Enter selection: "
    read selection
    echo ""

case "${selection}" in
  1) echo "you did a barrel roll..." ;;
  2) echo "you do the Bartman..." ;;
  3) echo "Yoda is proud of you..." ;;
  *) echo "Please select a valid option..." ;;
  0) exit 0 ;;
esac
done

You get the idea. However, your best bet may be popping up dialog boxes instead of doing an interactive shell.

[joelsenders]

Thanks for the responses guys. I really wanted to stay away from osascript just because I liked the idea of a rolling Terminal window and it being interactive. I'd rather not have different dialogs for every step of the script, which is what I believe would be required if I used AppleScript. The really annoying thing is that I swear this was working at one point. I don't know what I changed, but now it tells me it must be run as root and it didn't do that before (before "what" is the important thing, and I don't know what I changed).

tlarkin, this is what I was using to launch it as a post install script:

loggedInUser=$( ls -l /dev/console | awk '{print $3}' )

chown $loggedInUser:staff /private/tmp/script.command
sudo -u $loggedInUser open /private/tmp/script.command

I was thinking if I used sudo -u and the current logged in user, it would open in the their user space as themselves but with root access. Doesn't seem to be working. I guess, besides actually getting it working, I'm not understanding why this script wouldn't have root privileges if the Jamf binary is the one launching it. Can anyone speak to why it doesn't work that way?

[joelsenders]

I never expected this to be so difficult haha. I guess that's the way this stuff goes. I figured since the Jamf binary runs everything as root, I should be able to make this work without a hitch. Now it's more of the challenge of just figuring out if it's possible.

I'll better explain the scenario:

User A needs to run a script with sudo, but I don't want user A to enter a password. The script needs to run in User A's user space/GUI (it presents a window). Jamf binary runs as root. I call the script up with Jamf binary. My idea is for the Jamf binary to execute the script (as root) in User A's user space/GUI. That way User A can interact with the script, but does not have to use sudo.

The main reason I want to stay away from osascript is that I don't believe it can be interactive in a long scrolling window. I want the user to be able to refer back to information in the window instead of having dialogs that disappear after every prompt for input. If I'm wrong about this, I'd be happy to use osascript. Just not sure how to do that.

[tlarkin]

are you launching an app? What is your end goal with this workflow?

[joelsenders]

I just ended up using osascript. Oh well. Thanks for the help everyone.

[Nmangal]

@ joelsenders, Can you please let us know how you did it? As i am not able to launch Terminal as sudo by Self Service Policy.

Thanks in Advance

[blackholemac]

Is jamfhelper an option?