Scripting question

agardner
New Contributor III

So I have a question that I am sure someone smarter in scripting than me can answer. And maybe it has already been answered in another question. If it has, please direct me to that discussion.

I am trying to write a script that requires a sudo command. However I do not want it to prompt my user for the sudo password, as they are no sudoers. Is there anyway to su to my sudoer account within the script and run the rest of the commands and exit of the sudoer, without the user seeing anything?

Ideally, the script would look like this:

!/bin/bash

su "admin account"
sudo "command"
exit

instead I get...
su "admin account:
password prompt
sudo command
exit

I can't figure out what I need to add to my script to make this work.

Thanks, AG

3 REPLIES 3

allanp81
Valued Contributor

@agardner how are you going to trigger the script to run?

mm2270
Legendary Contributor III

Does this script need to be divorced from your Jamf Pro environment? What I mean is, is it a requirement that the script be run outside of jamf entirely (standalone)? If not, why not place it in Self Service? That's kind of what it's for - to allow end users without admin rights to run commands or installers with admin rights.

If the above isn't an option, there are some other options, but none are that great. You could, for example, use an expect block to pass the admin account password to the prompt, but this is very insecure. Especially if you plan on just giving this script in plain text to your users. They would be able to open the script in a text editor and would see the password in plain text, especially since you aren't pairing it up with a policy. If you were, the policy could send the password down to the script as a parameter so it wouldn't appear right in the script itself.

Another option would be to deploy a special LaunchDaemon that could watch for a file (WatchPath) and execute the script file or some other command when it gets triggered. Your 'end user' script could place something in the trigger file to make the LaunchDaemon do it's thing, as root. I've done things like this before as a type of workaround, but it's far from ideal, and I'll even say a little fragile to be honest.

Lastly, there would be a way to do this using an AppleScript, since AS has the ability to do commands with administrator privileges, but the script would still need to contain your local admin name and password. The main difference is, AppleScript lets you compile scripts as Run Only, meaning the end user can't open it up into the Script Editor or another application and read it. That doesn't mean it's impossible to get information out of the script, but it makes it considerably harder at least. So it's still not completely secure, but far better than using an expect block.
The command would look something like this in your AppleScript:

do shell script "shell command goes here" user name "admin_account" password "password123" with administrator privileges

If you can post any more details about what the script or the sudo command is doing, there may be other options that will come to light.

All that being said, I still think your best option would be to do this from Self Service if it's an option at all.

ianatkinson
Contributor

If you are running locally on the machine you can add a line to /etc/sudoers to allow the command you need, I do this with our printer unpausing script

BW-WKSDIGPR-99:login_extra admin$ sudo tail -1 /etc/sudoers
%everyone ALL=(ALL) NOPASSWD: /usr/sbin/cupsenable
BW-WKSDIGPR-99:login_extra admin$ cat /Applications/unpause_printers.command 
sudo /usr/sbin/cupsenable `lpstat -t | grep disabled | awk '{print $2}'`