Sudo allows you to manage / control the use-case when a user wants to execute commands as another user (usually as “root” but not limited to the super-user).

The generic sudo rule

UserList HostList = (RunAsUser) CommandList


  • You can assign an alias (a name) to a list of users (User_Alias), hosts (Host_Alias) or commands (Cmnd_Alias)
  • The alias name must have all capital letters and may have numbers but must start with a letter
  • Example
    User_Alias USERS_LIST1 = user_name1, user_name2, user_name3


  • The list of users this rule apply to
  • You can put
    • user names
    • OS user group (you need to prefix them with %): e.g %user_group
    • User ID (you need to prefix them with #): e.g #user_ID
    • Group ID (you need to prefix them with %#): e.g %#group_ID


  • The list of hosts the rule applies to
  • You can put
    • hostname
    • IP Address
    • Host_Alias


  • Commands must have the full path
  • Commands may have wildcards (e.g. /bin/* -> this will allow running all the commands from /bin folder)
  • Commands may also have parameters to restrict running the commands only on these parameters. Again, we can use wildcards on the parameters too (e.g. /bin/cat /var/log*)


  • The command will be executed on behalf (with the permissions) of this user. If RunAsUser is missing, the root is assumed (the commands will be executed as root). Else, you need to use the “-u” option to run the sudo command as that user.

    user_name1 Host1 = (user_name2) /bin/cat
    > sudo -u user_name2 cat file.txt

    Here we are running the “cat” command as user “user_name2″

  • You can put
    • a user name: (user_name)
    • a list of users: (user_name1, user_name2)
    • a user alias: (USER_ALIAS)
    • a group name: (:group_name)

You can use this as a value for UserList, HostList or CommandList to eliminate any restrictions.

user_name1 ALL = (user_name2) /bin/cat

Here user_name1 will be able to run /bin/cat as user_name2 on all machines.

If 2 or more rules conflict, the last matching one will win.

Use ! to eliminate from lists

 User_Alias LIST1 = %user_group1, !user_name1

This means that LIST1 refers to all the users from the “user_group1″ group except for user “user_name1″
Excluding using “!” is very useful for UserList, HostList or RunAsUser but not that useful for CommandList as if you eliminate a certain command from the list, the user may copy that executable binary to a different name and still execute that command…


  • Run “sudo -l” to find our what sudo allows to run for the current user.
  • Run “sudo -U user_name1 -l” to find our what sudo allows to run for the user_name1 user.
    • !!!NOTE!!! Only root and users that can run ALL commands on the current host can use the -U option.

Defaults and Options

  • Defaults can be used to control the default behavior of sudo.
    • “Defaults OptionList”
    • Types of defaults
      • Boolean
        • Defaults option_name1 -> enables option_name1 option
        • Defaults !option_name1 -> disables option_name1 option
      • Integer: options take a number as parameter (option name and parameter are separated by an “=“ sign)
      • String: similar to Integer but the parameter is a String now
  • Options can be set globally using Defaults but they can also be set
    • Per User
      • Defaults:UserList OptionList
    • Per Host
      • Defaults@HostList OptionList
    • Per Command
      • Defaults!CommandList OptionList
    • Per RunAsUser
      • Defaults>RunAsUserList OptionList

Allowing commands to execute other commands

There are commands that can execute other commands. Sometimes, this can be a security issue. For example, you can allow users to execute the “less” command with root privileges. However, while in “less” you can execute other commands (press “!” then execute the command) with root privileges.

In order to forbid commands to execute other commands, user NOEXEC:

> user_name1 ALL=NOEXEC:/usr/bin/less

This will not allow user_name1 to execute commands while using less

> user_name1 ALL=NOEXEC:ALL, EXEC:command_name1

This will prevent command execution from any command except from “command_name1” which really needs to execute other commands.

Managing environment variables

Environment variables are handled in several ways by sudo:

  • Whitelist environment variables: by default sudo removes all environment variables except $TERM, $PATH, $HOME, $MAIL, $SHELL, $LOGNAME, $USER, and $USERNAME. “env_keep” lets you tell sudo to keep other environment variables:
    • Defaults:%group_name1 env_keep += “ENV_VARIABLE1″
      • keep “ENV_VARIABLE1” environment variable for all the users part of the “group_name1” group.
    • “+=“ means add the environment variable to the current list. “=“ means overwrite the environment variable list with the newly provided one. “-=“ means deleting the environment variable from the current list.
  • Blacklisting environment variables
    • “env_reset” is the option that tells sudo to delete all the environment variable except for selected few
    • “env_delete” allows you to specify environment variables that should be removed.
  • Allow users to keep their environment variables
    • Use SETENV / NOSETENV tags on commands to instruct sudo to keep or not the user’s environment variables.
      • user_name1 host_name1 = (user_name2)SETENV:command_name1
        • Here, user_name1 is able to run command_name1 on the host_name1 host using user_name1’s environment variables.
        • You must run sudo with -E option to take into account the SETENV tag, otherwise sudo will keep on stripping all environment variables
          • > sudo -E -u user_name2 command_name1
    • Use setenv option to always keep environment variables for a certain user
      • > Defaults:user_name1 setenv
      • Use NOSETENV for certain commands to override this setenv
      • Again, you need to run sudo with -E flag
  • Run command using the environment of the target user
    • use the “-i” flag to simulate a login using the target user account (target user dotfiles like .login and .profile will be executed). This way you can run a certain command using the target account environment.
      • > sudo -i -u user_name1 command_name1
        • In this case the command_name1 will be executed using the user_name1 environment variables.
      • Used when we want to run an application with some configurations that are taken from environment variables (e.g. Java apps). In such case, you create a user with all these environment variables set and you run the application as that user.

When running sudo, there are 4 environment variables that are being set:

  • SUDO_COMMAND: the command you have run under sudo
  • SUDO_USER, SUDO_UID, SUDO_GID: the original user name, user ID and primary group ID.

Setting environment variables

  • secure_path allows you to set the path that will be first used by sudo when searching for a command. If the command is not used in secure_path, then $PATH is being used. This way you can make sure that users will not use bogus versions of applications (e.g. a hacked version of passwd) by providing them in $PATH variable.
    • > Defaults secure_path=“path1 path2 path3″
  • env_file used to provide a file with the environment variables to be set
    • > Defaults env_file=“full_path_to_env_variables_file”
    • Sudo adds these environment variables before stripping out the environment, so list any added variables in an env_keep sudoers rule as well.
    • This overrides the user’s own environment variables!

Sudo vs su

  • sudo is used to control commands execution as another user (use sudo to run a command as a different user, not to switch user identity). su is used to “switch the user”, meaning that you log in as another user (after running su, you actually receive the prompt and can run multiple commands as the new user)
  • in order to sudo, the user needs to enter his own password (even if the command ends up being executed as a different user) because the user only needs to prove his identity; the actual permissions (is the user allowed to execute the command as the requested user) are managed by the admin through the sudoers file. In the case of su, the user needs to enter the targeted user password, because you actually change the identity.

Turning sudo into suif shell_noargs option is enabled and sudo is run without arguments then you will receive the root prompt (so, just like running su).

  • Defaults:user_name1 shell_no_args
  • Running “sudo -s” does the same thing as enabling shell_noargs option
  • “sudo su -m” – run a shell but retain the user’s own environment
This entry was posted in Unix. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s