Shell Programming and Scripting

Hello,

I have a backup script that runs an rsync backup to an external drive. I use the script frequently on Windows and Linux and have installed it on a Mac. The script has an option to run shutdown after the backup has completed. Since backup can take hours to run, this is an option that is set when the script starts and is executed when the script is finished (usually long after I have gone to bed).

The script looks more or less like this,

Code:

#!/bin/bash

# read input to shutdown after script or not
echo " "
echo "do you want to shutdown after the backup is finished? (y/n)  "
read shutdown_response

...
backup stuff
...

# shutdown if asked to   
if [ "$shutdown_response" = "y" ]; then
   echo " "
   echo "shutting down"
   shutdown -s now
fi

# prompt to exit script if not shutting down
echo " "
echo "press enter to exit script"
read exit_response
sleep 1
exit

This works well on Linux and Windows cygwin. In MacOS, the backup works correctly, but I get an error from the shutdown command that I am not super user. This does not happen under Windows or Linux, I guess because I am running from an account with administrator. My user account on MacOS is administrator, but sudo appears frequently and apparently shutdown is one of the tasks that requires password authentication.

I can add a command to switch to super user, sudo su , so that when the user specifies that they want to shutdown they can enter their password (you have to use sudo to switch to su in MacOS, more or less).

That version looks like,

Code:

#!/bin/bash

# read input to shutdown after script or not
echo " "
echo "do you want to shutdown after the backup is finished? (y/n)  "
read shutdown_response

# shutdown if asked to   
if [ "$shutdown_response" = "y" ]; then
   echo "enter your password for shutdown"
   sudo su
fi

...
backup stuff
...

# shutdown if asked to   
if [ "$shutdown_response" = "y" ]; then
   echo " "
   echo "shutting down"
   shutdown -s now
fi
# prompt to exit script if not shutting down
echo " "
echo "press enter to exit script"
read exit_response
sleep 1
exit

It looks like sudo su opens a new subshell and so the script does not continue to run. I really can't see an easy way around this. Maybe I could have a calling script that would run two different versions of the backup script, one called with sudo and the other not, but I'm not sure about that.

Is there a standard way to handle this?

LMHmedchem

You don't need to sudo, just run it from the admin account on the Mac and move on to other tasks.

That way the script stays the same and you don't need to be bothered using sudo to run a simple, basic MacOS admin backup task.

First off, i can only emphasize what Neo already said. This is the best solution from a practical POV. But since you may want to understand your system better i will try to explain what happened anyway:

More or less - but not quite.

First, yes, the shutdown command can only be issued by the root user. UNIX is a multiuser system at its core so the "default use case" it was built with in mind is some dozens of users using the same system at the same time. You don't want any of them to shut down the system whenever they feel like it in such a setting. This is why only root (or sometimes a special user group "wheel") is allowed to do it.

Now, everybody can - in principle - use the command su to switch the user. What su does is to open a subshell (you are correct in your assumption that it does) with the new rights and you are that new user as long as you do not leave this shell again. Notice that there are two (three) ways to run su:

Code:

su newuser
su - newuser
su - newuser -c command

Let us first talk about the difference between the first and the second: without the dash ("-") in between the environment of your own user is preserved. Variables like "PATH" and everything else you have set remains even though the user credentials change. With the dash, though, your environment is completely overwritten by the environment of the new user, effectively it is like doing a login as the new user - complete with executing the profile and whatever else is done during a normal login. In both cases, once you leave the subshell this is reverted back because all the changes are made within that subshell.

The last variant (which i have written only once but in fact it can be done in the with-dash- or the without-dash-fashion) does the same but within the resulting subshell only the specified command is executed and the subshell is left immediately afterwards. This way you can do single commands*) as a different user.

When you try a su command you are asked for the password of the user you try to switch to, just like you are asked for the password when you log in as that user.

Finally, what does sudo do? Well, certain commands (like su, but also others, shutdown, halt, ...) are deemed so security-relevant that one doesn't want to rely on all users being prevented to use them by just not knowing the relevant password. So all these commands would be made unavailable for all (normal) users at all. Nobody could use su any more. No, a select few users should be able to do it, though, and for this there is sudo. It allows certain users to run certain commands under different rights.

So, basically it goes like this: su is forbidden to use for everybody. But userX can use sudo and it will executed su for him as root (which can't be prevented from using it) so userX can still - with the help of sudo - execute su. UserY, for which this rule does not exist, can't execute su even though knowing the root password, because su is not allowed for anybody - he would not even be asked for that password. Which user is allowed to do what using sudo is laid down in a list of rules in the file /etc/sudoers.

Since many UNIX systems are effectively single-user these days (perhaps only you use your Mac and nobody else) it is common to add a sudo-rule for that user that allows for any program to be called via sudo and in turn being executed as root. So, this is where sudo shutdown comes from. sudo does not ask for the password of the user it runs the command as but the password of the user who invokes it - to make sure it is the user for whom to check if there is a rule allowing that.

No, you don't - it is just common. If you know the root password you most probably can do a

Code:

su - root

(notice that the "root" is implied if no user is specified so su - is the same) and you will be asked for the password of root and then become root. When entering

Code:

sudo su - root

you will be asked for your own password instead (by sudo, not by su) and then sudo wil call su as root (no password question from su therefore) to do an su - root for you.

This results - as a side effect - in nobody having to know the root password any longer and that is a second reason why it is done that way. Usually the root password is generated by a software and then thrown away. So nobody can become root save for the "backdoor" by having a rule in sudo that does it for him. Since sudo rules can be broken and sudo will refuse to work if /etc/sudoers contains syntactical errors it is still a good idea to know the root password just in case. Simply switch to root using sudo and change the password to some value you know by using the passwd command. In big companies this is done too, usually by someone not from the administrator team. The password is then sealed and kept in a safe where you can obtain it should the need arise.

Finally, how should you do the backup: you should run the whole backup process as user root because this way you avoid the possibility that your user may not be allowed to access some data and hence cannot backup them. When you do it like this you can shutdown at the end or not without any additional password. Furthermore, instead of asking interactively, i would use an option to select an optional shutdown at the end:

Code:

mybackup -s   # shutdown at the end of the backup
mybackup      # no shutdown at the end of the backup

Interactive parts in script prevent them from being called by other scripts. If you use an option instead you could build some other script which as one step calls your backup script. You couldn't do that (actually you could but it would defy the reason for a script, namely to make things automatic) if it has interactive parts.

I hope this helps.

bakunin
________________
*) note that "single command" here includes scripts including several commands as well as lists of commands - to be precise this should read "list" instead, like i.e.:

Code:

su - newuser -c "command1; command2; command3"

Thank you for taking the time to put together this informative post. I'm sure that others will read it as well.

Some of my issue was how to go about running from the admin account. The account I am in is already administrator , but I get permission denied when I try to run shutdown from a script. To authorize shutdown, I can run the script as, sudo scriptname , or I can su and then call the script.The default root account is disabled on many Mac installations, so you are not supposed to be able to change the user to root without activating the root account first. Please let me know if I am not correct about any of this.

One thing I was trying to accomplish was to have this all run without having to launch a terminal, navigate to the script location, and run the script. I can do that, but there are others who may use this machine who cannot. I wanted to set it up so that an Alias to the script could be double clicked on, the script launched in Terminal, and the user prompted for their password.

Apparently there is an issue in MacOS when you just try su. If you just do su you get an error even though you have entered your administrator password. If you do su root and enter your password, everything works. This is odd since the root account is supposedly not active.

This is an important point, especially in that the version of rsync that ship with MacOS is fairly old and seems to have some issues with metadata. If you run rsync with -E (preserve file execution permissions) and don't run as root, you get a whole long list of errors in your log file. If you are backing up your entire profile directory, there are allot of hidden system files there that will be skipped if you don't run as root.

This again goes back to not wanting to have to call the script from a Terminal. There are always choices to be made and so I guess there is no perfect solution.

This is one method I found that works. This is a little script that adds a username to /etc/sudoers and sets the user to be able to run sudo rsync without a password. You double click on the script, or script alias, enter the username, and enter your password. The proper entry is added to the sudoers list.

Code:

#!/bin/bash

# check if user exists in /etc/sudoers
# if not, add user and recheck
function add_user_and_check () {
   # check if the user entry already exists
   if sudo grep -q $user_name" ALL= NOPASSWD:/usr/bin/rsync" /etc/sudoers; then
      echo $user_name "already has the correct privileges"
   else
   # add the user
   sudo bash -c "echo \"$user_name ALL= NOPASSWD:/usr/bin/rsync\" >> /etc/sudoers"
      # recheck
      if sudo grep -q $user_name" ALL= NOPASSWD:/usr/bin/rsync" /etc/sudoers; then
         echo "success: the user was given rsync sudo privileges
      else
          echo "failure: the user was NOT given rsync sudo privileges
      fi
   fi
}

# get the username to add
echo "enter the username you want to add"
echo ""
read user_name

# get the password and call the function with sudo
echo "enter the administrator password"
echo ""
# call the function in a subshell as root
sudo su root -c "$(declare -f add_user_and_check)"; add_user_and_check
echo ""
echo "key \"Enter\" to exit script"
read exit_now
sleep 1
exit

My understanding is that because the function is declared and then called as root to run in a subshell, the instructions in the function can all run under root privileges. It is necessary to call the function instructions like grep and echo with sudo or you still get permission denied errors. My guess it that you could run the backup script as root using the same method, namely having all of the backup code in a function that is declared and called in the same way. You would start the script by double clicking on the script and then enter your password. The script function would then run as root. I don't think your function call other functions using this method, which is a drawback if true.

I opted for now to add the user to the sudoers list with $user_name ALL= NOPASSWD:/usr/bin/rsync so that rsync can run as root without a password. This has worked in tests so far in my tests.

LMHmedchem

Why are you feeding a function which calls sudo, into sudo? And then you don't even use it, just call it outside sudo afterwards.

Further, you really shouldn't be editing /etc/sudoers like that. sudo on most systems will refuse to operate after /etc/sudoers has been edited by anything but visudo.

Hi LMHmedchem...

Take a look at post #2 here, it might be of use:

Root access in OSX 10.12.2.

This is mostly an exercise in ways to run a script with root privileges without a user needing to open a terminal, navigate to a directory, and either call the script with sudo or su root from the terminal and then call the script. These are actions that are beyond the abilities of a sizable number of users who still may need to perform tasks like running a backup as root. I am trying to create a script that can be run by double clicking on a desktop icon, entering a password when prompted, and have the script do the rest with the privileges it needs. I don't have any problem running a script as root, but that is not the case for every user.

The method I used in the script above prompts the user for a password when sudo is invoked for the function call, but the password is not requested for any of the commands in the function. The password is required once at the beginning and not again. This is the behavior I am looking for. The sudo command still needs to be in the commands in the function, or you get errors. This doesn't make sense to me because the intent was to run the function in a subshell as root. It does, however, run without error and gives the expected output.

I have confirmed with visudo that running the sudoers script does add the the correct line to the file. I don't notice any issues running sudo with other commands, but I need to dig a bit deeper to make sure that the backup script is actually running as root (directories like /Library are being copied) after making the sudoers edit the way I did above. I know that the script was running as root when I made the $user_name ALL= NOPASSWD:/usr/bin/rsync entry to sudoers with visudo but I haven't checked it carefully with the other method. The edit of the sudoers list is important in order to be able to run a scheduled unattended backup as root.

LMHmedchem