Running software as Superuser


The focus on this section isn't so much about interesting ways to run programs. (Getting a program to run at all can sometimes be a challenge itself. For instance, trying to run a program from a remote location, using a specified username, is a different topic, although that may be a somewhat related topic. If interested in checking that out now, one option is described in the section about using authorized key files (specifically the section about running commmands over SSH using an SSH key). Another method to do such a thing is to have a web browser run a program, possibly by using the “common gateway interface” (“CGI”).) Rather, the focus here is more about handling the permissions, with the focus on getting “superuser” privileges.

One way to be have full superuser permissions/privileges/rights is to log into an account with those permissions/privileges/rights automatically granted whenever that account is logged in. Actually, it is often good security to not have such full permissions available for any account that doesn't have logins disabled. Instead, rely on users not having such full permissions except in cases where an user is requesting elevated permissions. Of course, any such request should not be honored unless the request is coming form a source which as provided authentication requirements needed to obtain such permissions.

Technical How-To

So, here are the technical details about providing superuser access when a program is run as a specific user:

In Unix
The sudo software suite
[#sudoname]: The name of the su command meant to do something
Better than using the su command, and then separately letting the computer know that a user wants to do something, the command that is recommended is called sudo. Some people intuitively start to refer to the program as if the name rhymes with “sumo”, and that probably makes sense for people who come across the name without first knowing the background. However, it is actually pronounced “sue-doo”. The reason is because this name is a compound word, consisting of the name of the command su and the verb “do”. The idea behind sudo is that it allows a user to become a superuser like the su command, and then to proceed immediately to “do” what is specified on the command line. The reason that rhyming with “sumo” just feels wrong to people who understand this is because the end user doesn't become a user like as if the su command is run and then “doe” the command specified on the command line. Some people argue that if it were meant to be pronounced as sue-doo then it would be spelled sudu, perhaps meant to be similar to the family name of the spelling of Star Trek's fictional character Lieutenant Hikaru Sulu. That might be a compelling arguement if it wasn't for the existing simple arguement of the whole “su, then do” context of sudo's name.
Using sudo / su

These programs may require some setup to allow specific user(s) to elevate permissions (in general, or perhaps only to run certain software). However, the likelihood is that if things are not set up sufficiently, the main consequence is likely that the attempt will be reported as an unauthorized attempt to use the programs. This may not be a big deal (possibly depending on what happens with such a report, such as whether or not that causes alerts that bother any other people).

The fast way to perform this, if the software is set up and will work nicely, is to use “ sudo command-to-run ” such as “ sudo sh ” (or a different command like a more preferred command line shell).

To use su, the simplest method is to just run it by itself, su.

However, it is recommended to get into the habit of using “ sudo command-to-run ”. There are multiple reasons. Perhaps the primary reason is because sudo will allow a user to quickly run a command and automatically exit the elevated status, returning back to the initial (probably less privileged) status. This may reduce the amount of time that a system is (needlessly) logged in with privileges available, and that general practice may reduce security risk. Also, typing a sudo command will also likely be faster than first running su, then seeing if that attempt succeeded (or if su is asking for a password, in which case the attempt to elevate privileges is still in the process and hasn't yet succeeded), and then typing the desired command (and then, whether immediately or later, closing the extra command shell that gets used). Also, sudo commands will typically show up in a command line history, while the commands run within an su session may not be recalled quite as easily.

Setting up the software

Making sure the sudo / su software is installed

Check if the excellent package known as sudo exists.

To see if sudo is installed, try running “which sudo” If the command is not found, then it is probably not installed. (There could be other reasons, but the most likely reason is probably that the software hasn't been installed.) Many operating systems are now bundling in sudo. Alternatively, the program su may be used if it exists, although in such cases it is still recommended to install sudo. See the software installation guide for instructions on installing software such as sudo. The home page for sudo at may be useful if a package system isn't available.

Adding support for user(s) (or group(s))

Choose one of the following sections to either add support for a group, such as a group number 0 called “wheel”, or instead to add support for a desired user. The generally preferable way is likely to use the “wheel” group.

Using the “wheel” group
Adding to the wheel group

Make sure that the end user is part of the group called “wheel” (which generally should be group number 0). (Details are available in the sections for verifying who is part of a group (or the relevant information can be checked by verifying what group(s) a user is in) and, as needed, putting a user into a group.) (Why use a group named “wheel”? Simply because using a group called “wheel” is a commonplace standard. For those curious about the precedent, Wikipedia page on the group called wheel may have some basic background history.)

[#sudokgrp]: Authorizing the members of the wheel group
Back up the original /etc/sudoers file
Quick backup guide for files that are about to be changed
ls -td1 /origbak/ver* | head -n 1

(If the output of this command is “ls: /origbak/ver*: No such file or directory” then /origbak/ver1 may be used. If the output had said “/origbak/ver36” then we would be using the next higher number: “/origbak/ver37.”)

This may require root access to be making a new subdirectory directory under the root directory. Normally such a process can be done with sudo. However, it may make sense to back up the user database before setting up sudo. If that is being done, simply try su and use the password of the root account.

Then, once root access is obtained, copy the files.

In this example code, we will be using /origbak/etc/ver2/.

mkdir -p /origbak/ver2/etc
chmod go-rwx /origbak/ver2/etc /origbak/ver2 /origbak
cp -p /etc/sudoers /origbak/ver2/etc/.

In this case, it is not recommended to exit out of the elevated, privileged login. The simple reason is because such rights are likely needed in the very following steps.

[#visudoed]: Choosing an editor

An upcoming step involves editing a text file with the visudo command. There are probably good reasons for running visudo, which are probably similar to the good reasons for running vipw when making changes to the password file. Despite its name, the visudo command may run an editor other than the vi command. It can be beneficial to know what commands may be getting run every time another command is run. Following are steps to determine which editor visudo will actually be running.

Presumably, the visudo and the sudo commands will likely both have the same behavior of either supporting or not supporting the EDITOR environment variable. Find out which is true by running:

visudo -V | grep EDITOR

That command might or might not result in output such as the following:

Visudo will honor the EDITOR environment variable

If that desirable text is installed, feel free to use an installed editor of your choice. (See the section about choosing a text editor.) Set the $EDITOR value if desired. (If needed, see the section about setting an operating system environment variable if needed. e.g. perhaps use export EDITOR="nano -w").

If the EDITOR environment variable is not supported, the manual page for the visudo command (manual version 1.8.1) has information about what editors may be allowed. That manual page indicates that vi might be the only editor allowed before the configuration file is updated.

[#visudwhl]: Modifying the /etc/sudoers file to enable the “wheel” group to sudo

Directions to modify the /etc/sudoers file were here, but are now in a new location (as a section that is now shorter, because it has been seperated out). Check out the instructions in this section: directions for editing the /etc/sudoers file.

Supporting a different group

The main reasons to use the group named “wheel” are the standardization that comes from long-standing precedent, the fact that the default /etc/sudoers file has references to the “wheel” group, and that some operating system installation procedures may place administrator accounts into the “wheel” group. Other groups could be used: simply make sure any needed user is in the other group, including making sure that group exists, and have /etc/sudoers reference the other group name instead of “wheel”. (References to the other group name, like references to %wheel, will start with a percent sign (“%”) character.)

Adding support for a user

The process is essentially the same as supporting a group, except that usernames start with the username at the beginning of a line, while groups are specified by having a percent sign (%) prepended at the start of the group name. (The combination of the percent sign and the group name are at the beginning of a line.) So, simply add a line for each user. Details of what that line should look like are in the section about supporting the “wheel” group. Simply take off the % on any uncommented line, and reference the username insetad of the name of the group (which is “wheel” in the example of handling a group).

Editing the /etc/sudoers file to support each user is probably more cumbersome, in the long run, than just setting the /etc/sudoers to use a group and then modifying that group membership as needed. However, this method is an option.

For details, follow the section about supporting the wheel group as a guideline, but replace the reference(s) to %wheel with references to the desired username. (Place each username on its own line in the /etc/sudoers file.) If using vi, the instructions about using the editor vi should describe how to delete the characters that make up the word “wheel”, and to insert the characters of a different group name.)

[#sulimcmd]: Restricting what commands an authorized user may run

Perhaps a user needs to have partially elevated permissions: the user needs to be able to run a command to perform a specific task, like mounting a directory or rebooting a system or running a backup, but it is not desired to provide user access to have run any command with elevated permissions. The sudo command does allow such restrictions.

To do this, modifications will be getting made to the /etc/sudoers file. (So, back up that file, and see the section about choosing an editor for the /etc/sudoers file.)

Use the visudo command to place a line in the /etc/sudoers file, but then add a line that specifies the start of any authorized command. For example, if the user account was named _endsys, then the /etc/sudoers file may have something like:

_endsys  ALL=(ALL) NOPASSWD:/sbin/shutdown -h*, SETENV: ALL

This will allow the user to be able to run a command such as:

sudo /sbin/shutdown -hp now Comment For The Logs

The command is allowed because it starts with the command shown in the line added to the /etc/sudoers file (and that line did have a * character to indicate some flexibility may be allowed). If the user tried to use:

sudo /sbin/shutdown -ph now Comment For The Logs

then the sudo command would not cooperate (even though the shutdown command might not care about the order of the command line parameters).

[#suacctna]: “This account is currently not available.

The apparent problem is that when using “sudo -i”, the displays the message “This account is currently not available.” Then the program does something that seems sensible, if a needed account is not available: the program exits with a return/exit/errorlevel value/code of 1 is generated. However, even if that behavior is sensible, it probably isn't what was intended by the person who tried to run the command.

The reason for this error is that sudo -i will refuse to run if /etc/passwd shows /sbin/nologin for the user's shell. To help keep security high, it is overall a generally good thing if the “root” user has /sbin/nologin as a shell. So, rather than fixing the issue by altering permissions, a way to work around this issue may be worth pursuing.

In the short term, it may be best to just work around the error message by not using the -i command line switch. Doing this avoids any benefits of convenience that were probably trying to be reached by using “ sudo -i ”. And, a slicker workaround may be available. However, the slicker workaround may not be quite as straightforward to memorize/type, so to just get instant results in the short term, this workaround may be desired. To pull this off, first run a shell as a superuser, by simply using sudo without the -i parameter. Once at a command prompt with superuser privileges, note that a common reason to want to use “ sudo -i ” might be a desire to control what environment variables are set. Since sudo is being run without the “-i” parameter, those variables may need to be manually/carefully set again (before running the desired command which may use those environment variables). Once everything is set up properly, run the desired commands.

The following was found to work (on a system where sudo did not ask for a password). (A note which may or may not be very relevant: This was on an OpenBSD machine where the sh command was OpenBSD's ksh executable.)

sudo su -ls $(which sh) root -l -c "cmdtorun otherOpts"

In the above example, the “ otherOpts” represents command line options that are completely optional, and this may be left off entirely if the command being run does not require any command line options. The cmdtorun is also meant to be customized.

Note that this example may work for simple commands which don't have complications such as quotation marks as part of the commands. For commands that are more complex, this complicated example may actually be simpler than what will ultimately be needed. (The precise details of what is needed may depend on details, like what sort of special characters are being used, as well as details about how those characters are interpreted by the current shell and/or the shell that gets run. That's pretty variable, which is why this guide isn't just providing a cookie-cutter solution. Some thought and/or safe experimentation may be warranted.)

Making a script

The above command is a bit of typing, and certainly quite a bit to try to memorize. If this is a task that may be performed regularly, it may make sense to create a script file. (This is untested, but will probably work as shown.) Since the contents of the file contains charcters which may be interpreted by a running command line shell, either use a text file editor (which is probably preferred), or escape those characters as needed (which will probably be a bit more complex: details are not provided in part because the proper command would be a bit shell-dependant). The contents of the script file's source code may be:

sudo su -ls $(which sh) root -l -c "$1"

Again (like when running the command directly, instead of from a script file), that may work for more simple commands. For more elaborate commands, such as anything with a quotation mark, the script file probably doesn't need to change at all. However, the parameter passed to the script file may need to escape such characters (possibly with multiple sequential escape characters?).

An enhancement for the command line, which may work for some shells (including OpenBSD's ksh, and perhaps bash?), is to use “$(which ${SHELL:-sh})” instead of just “$(which sh)”.

[#sux]: sux

Apparently there is software to allow a superuser to run X software sandboxed, and it is called sux. This is mentioned by: sux

(At the time of this writing, the software called sux did not appear to be a part of the sudo suite. The command called sux is not being mentioned because it is recommended to use, but rather than the topic seems related to the topic being discussed, and so may be relevant and worth researching further.

In Microsoft Windows

In Microsoft Windows Vista and newer versions, there are two different concepts that are often described as running a program as an administrator.

Understanding the “Run as administrator” option
Where is it

There is a lot of misunderstanding about the “Run as administrator” option. Before clarifying that misunderstanding, let's discuss an example of how to see the option that is being talked about:

If interacting with Explorer's shortcut/context/“right-click” menu does not showing the needed option to run as another user, holding down the shift key when right-clicking may cause the option to appear. (That may not happen, though, if HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\HideRunAsVerb is set to 1.)

What it doesn't do

Many people seem to think that Explorer's “Run as administrator” option is somehow related to running a program using the Administrator account. This is flat-out false. This icon has nothing to do with which account a program will run under.

When you see that option, it is related to having a program running with what user account control calls “elevated permissions”. (If UAC is sufficiently disabled in Windows Vista which introduced UAC, then that option just disappears.)

To run the program as an Administrator, there may be multiple options. As just-mentioned, one possibility just involves removing UAC restrictions. Another option is to follow the details are in the section for running a program as another user. Naturally, the user account which will be running the program needs to an Administrator.

Changes that involve multiple machines, such as changes made to a domain user account or changes to group policy settings that will affect multiple machines, may often require being a Domain Admin. Many other changes which are specific to just one machine will often only require that the user is part of the local machine's Administrator group.

Make sure that the user is part of whatever group the user needs to be a part of. This may be done indirectly, by making the user part of a group, if the group containing the user is (directly, or indirectly through another group or series of groups) part of the desired group. For example, if UserX needs to be a local Administrator, and UserX is part of a custom SiteAdmins group, and the SiteAdmins group is in the local Administrators group, then UserX is effectively (indirectly) a part of the local Administrators group, even though UserX's username may not show in a simple list of the users and groups that are directly part of the Administrators group.

As needed, see the section for adding a user to a group in Microsoft Windows.