- "Do I Know This Already?" Quiz
- SSH (Secure Shell)
- Executing Commands as Another User
- Summary
- Exam Preparation Tasks
- Define Key Terms
- Review Questions
This chapter is from the book
This chapter is from the book
This chapter is from the book
Executing Commands as Another User
There are times when you need to execute a command as a different user account. For example, if you log in to the system as a non-root user, but need to execute a command with root privileges.
This section describes methods of running commands as different user accounts, including the sudo command, the su command and the pkexec command.
The sudo Command
The problem with the su command is that to provide a user with elevated privileges, you need to provide the user with the root password, which would give that user full administrative access to the system.
Often you want to allow a regular user to execute some commands, but not all commands, as the root user. For example, if a network error occurs on a user’s workstation, you might want that user to be allowed to restart the networking service. On some systems, this can be accomplished by executing the following command:
# /etc/rc.d/init.d/network restart
To execute this command successfully, the user needs to have root privileges. This is where you either give the user the root password (which is not recommended) or you give limited root access the correct and reasonable way, via the sudo command and its partner tools.
Instead of providing the user with the root password, you can set up the sudo command to allow the user to run just the necessary command. To do this, you need to log in as the root user and then execute the visudo command.
# visudo
This command allows you to edit the /etc/sudoers file, the file that allows you to provide root access for specific commands to specific users. The visudo command automatically assumes that you want to use the vi editor to edit this file. To use a different editor, such as the nano editor, execute a command like the following:
# export EDITOR=nano
The sudoedit Command
One of the conundrums of granting a user access to edit a configuration file is that if you are using vi/vim, you are essentially giving the user the ability to run any command as root.
To prevent a user from gaining shell access with a simple set of keystrokes from vi/vim while running it as root, there exists the sudoedit command, which is really just a symbolic link to a function contained in the sudo command.
The sudoedit command lets you allow a user to use any editor, not just vi/vim. It also enables the user to edit the using sudo access, rather than having to log in to the root user account.
When a user edits a file by using the sudoedit functionality, a temporary copy of the file(s) is made, and it is owned by the user in question. Since the user is now the owner of the temporary file(s), he can successfully edit the file(s) without having root access. Upon saving the file(s), the temporary copy owned by the user is copied back to the original file location, and the original ownership is restored; the now unnecessary temporary copy is discarded.
To configure sudoedit, add the following line to the /etc/sudoers file:
%newsudo ALL = sudoedit /some/path/to/a/file
Configure the newsudo group in /etc/sudoers to have the users you want to use sudoedit, and then all they need to do is run the command:
sudoedit /path/to/that/file
The /etc/sudoers file has many options. For the Linux+ certification exam, you just need to know how to provide a user with the ability to execute commands as the root user. For example, if you want a user account with the name ross to be able to run all commands as the root user, add the following line:
ross ALL=(ALL) ALL
To limit a user to a specific command, such as the /etc/rc.d/init.d/network command, add the following line:
ross ALL=(ALL) /etc/rc.d/init.d/network
For a user to execute a command as root, she needs to use the sudo command. The syntax is as follows:
# sudo /etc/rc.d/init.d/network restart
The user is then prompted for her own password (not the root password). If the correct password is given and the access is permitted based on an entry in the /etc/sudoers file, the command is executed as the root user. If the user attempts to execute a command that she is not authorized to execute, an error message appears on the screen, and the attempt is logged.
User Privilege Escalation
Users on a Linux system come in the following types, and it is important to know all three types, which type you are logged in, and how to escalate or deescalate your privileges at will by switching from one type to another:
Root: This is the root user, who is the super user and the most privileged user on the system. There should be only one of them, characterized by the name root and the UID (user ID) 0.
Standard: Otherwise known as “regular” or “normal” users, these are the rank-and-file users on the system; they have no special privileges and typically have UIDs that range from 1000 and higher.
Service: These are the accounts that have to exist to ensure that every service or daemon on the system is running as a user, since every process must have a user attached. These accounts are never signed into; they exist in the /etc/passwd file and may even have /bin/nologin as the specified shell.
The best security practice is to avoid logging in as the root user unless you need to perform specific administration commands. In most cases, you should not log in as the root user directly but rather should gain root access by executing either the su command or the sudo command.
If the wheel group is configured to have privileged access via sudo and the /etc/sudoers file, then adding a user to the wheel group gives the user those privileges. For example, in our openSUSE system, the wheel group is set up to be able to allow members of that group to execute any command, just as the root would be able to:
%wheel ALL=(ALL) ALL
This entry is normally commented out, but it would be very easy to remove the single # comment in front of it in the default file to enable the wheel group (and its members) to have full administrative access to the system.
The su Command
To gain access to another user account with the su command, use the following syntax:
su account_name
For example, to switch to the root account, execute the following command:
# su root
This provides you with a non-login shell for the root user. Typically you want a login shell because it provides you with the full user environment (environment variables, shell customizations, and so on). This can be accomplished by using the -l option or just a - option:
# su - root # su -l root
To gain access to a regular user account, you must provide the account name. However, if you don’t provide an account name, the su command assumes that you want to switch to the root account. As a result, the following commands are all the same:
su - root
su -l root
su -
su -l
When switching from the root account to a regular user account, no password is required. This means the root user can switch to a regular user account to test that account’s features (or troubleshoot problems for the user) without having to change that user’s password.
To switch from a regular user account to any other account, you must know the password of the account you are switching to.
PolicyKit
PolicyKit, also known as polkit, is a system service in Linux that provides a framework for controlling system-wide privileges and permissions.
PolicyKit exists to provide application-level definition and handling of unprivileged access to privileged processes. For example, you might use PolicyKit to provide a user the ability (and the rights) to perform a task by executing a command with elevated privileges. If you think that sounds like the sudo command, it’s understandable, because they both have fairly similar goals.
One difference is that PolicyKit is a little easier to use, and certainly less tedious, because you don’t have to preface almost everything you do with the sudo command.
The pkexec Command
With the previous discussion of the PolicyKit package, pkexec makes a lot more sense, as it’s the most common way to utilize the PolicyKit rules.
The pkexec command, when used to run another command, will execute that command as the targeted user. The user can be specified, but if it is not, pkexec attempts to execute the target command as the root user.
For example, to execute the lemmy.sh script as the root user, you would type
# pkexec lemmy.sh
Since a user is not specified, the default for pkexec is to attempt to run the subsequent command, script, or executable as the root user.