I have a script which can run as sudo script.sh or pkexec script.sh
It would be much nicer from the user point of view if the script asked for the password from the user when just running it by name script.sh.
How can I "embed" request to pkexec or sudo to run the whole script with root privilege?
Note that running everything with sudo sh -c might not be the best solution as I have functions in the script.
This'll work:
echo "$(whoami)"
[ "$UID" -eq 0 ] || exec sudo "$0" "$@"
example:
./test.sh
blade
[sudo] password for blade:
root
blade19899's answer is indeed the way to go, however one could also call sudo bash in the shebang:
#!/usr/bin/sudo bash
# ...
The obvious caveat is this will work only as long as the script is called with ./script and will fail as soon as the script is called with bash script.
bash script on the command line to invoke a script. If the script specifies anything other than bash in the #! line, then invoking it with bash script is going to fail. If I tried to invoke a python script using bash script.py it would also fail.
– kasperd
Mar 16 '16 at 12:48
perl script, though. Perl, in an effort to be really really nice, checks the shebang line, and if it's not invoking perl it runs the correct program.
– tbodt
Mar 16 '16 at 22:23
If you'd like a pretty dialog, try something like this. I ripped this straight out of something else I wrote, so it's got extra stuff you might not need or want, but it shows the general idea:
brand="My Software"
# Check that the script is running as root. If not, then prompt for the sudo
# password and re-execute this script with sudo.
if [ "$(id -nu)" != "root" ]; then
sudo -k
pass=$(whiptail --backtitle "$brand Installer" --title "Authentication required" --passwordbox "Installing $brand requires administrative privilege. Please authenticate to begin the installation.\n\n[sudo] Password for user $USER:" 12 50 3>&2 2>&1 1>&3-)
exec sudo -S -p '' "$0" "$@" <<< "$pass"
exit 1
fi
This uses whiptail, which you can install if you don't already have it:
sudo apt-get install whiptail
exec echo [PASSWORD]! It'll spawn a process with the password on the command-line that any user can see. Either use the built-in command echo (force the built-in version with builtin echo) or the bashism <<< (like so: sudo ... <<< "$pass"); Sh and other shells have Here Documents for these cases. Also, quote the password in case it contains special characters.
– David Foerster
Mar 16 '16 at 03:58
whiptail command into a separate script and use something like SUDO_ASKPASS=/path/to/askpass-with-whiptail.sh sudo -A -p "My password prompt" -- "$0" "$@" to have sudo deal with the custom password prompt.
– David Foerster
Mar 16 '16 at 04:12
/dev/mem to find the user's password in free memory and hope you find it before the kernel zeroes it out and hands the freshly sanitized memory to another process... How do you expect to read free memory without being root?!
– Michael Hampton
Mar 16 '16 at 07:32
It appears that nobody else has addressed the obvious concern here. Putting sudo within your script that you then distribute promotes bad user habits. (I'm assuming you're distributing it because you mention "from a user point of view.")
The truth is that there is a guideline in using applications and scripts which is similar to the security principle in banking of: Never give out your personal information to someone who calls you and says they're calling "from your bank", and which exists for similar reasons.
The rule for applications is:
Never type in your password when prompted unless you are certain what is being done with it. This applies triply to anyone with sudo access.
If you're typing your password in because you ran sudo on the command line, great. If you're typing it in because you ran an SSH command, fine. If you're typing it in when you log in to your computer, great, of course.
If you just run a foreign script or executable and tamely enter your password when prompted for it, you have no idea what the script is doing with it. It could be storing it in a temp file in plaintext, for all you know, and might even fail to clean up after itself.
Obviously there are separate and additional concerns about running an unknown set of commands as root, but what I'm talking about here is maintaining security on the password itself. Even assuming the application/script is not malicious, you still want your password to be handled securely to prevent other applications from getting hold of it and using it maliciously.
So, my own personal response to this is, the best thing to put in your script if it needs root privileges, is:
#!/bin/bash
[ "$UID" -eq 0 ] || { echo "This script must be run as root."; exit 1;}
# do privileged stuff, etc.
sudo script_name is just as vulnerable, it's the same. Maybe this idea does promote bad habits - I won't say anything about that. But the key is knowing what a program does, and that's user's responsibility. That's the whole idea behind open-source software. As for my own script, well . . . a script is plain text - users can read it if they wanna know what it does
– Sergiy Kolodyazhnyy
Mar 21 '16 at 09:34
I preface the commands within the script which need root access with sudo - if the user has not already gained permissions, the script prompts for a password at that point.
example
#!/bin/sh
mem=$(free | awk '/Mem:/ {print $4}')
swap=$(free | awk '/Swap:/ {print $3}')
if [ $mem -lt $swap ]; then
echo "ERROR: not enough RAM to write swap back, nothing done" >&2
exit 1
fi
sudo swapoff -a &&
sudo swapon -a
This script can either be run as sudo <scriptname> or as <scriptname>. In either case it will ask for the password, only once.
sudo for 25 different commands redundant - it's easier to call sudo once. Here however, the reason your script calls sudo only once is because sudo has time out of 15 minutes - commands that take longer than that will need to be reprompted. Your way works just . . . not the way I need it to work.
– Sergiy Kolodyazhnyy
Mar 15 '16 at 16:41
I did it this way:
echo -n "Enter password for sudo rights: "
read -s pass
echo $pass | sudo -S [your command here]
exec- call itself but at the same time replacing process , so we don't spawn multiple instances of the script – Sergiy Kolodyazhnyy Mar 15 '16 at 16:54"$@"will expand to multiple words, one for each parameter. – jwodder Mar 16 '16 at 21:37