How To Become Root
It is highly recommended that GUI interfaces not be run as root. That can easily lead to disaster. It is best to log in as a normal unprivileged user and to only use root's powers as required.
1. Using the su command
Many commands can only be run as the root user so to run these commands we need to become "root". To do this, we can use the su command (substitute user). The su command takes the following format:
su - <user>
or
su <user>
but most commonly we will use su to become the root user:
su - root
or
su root
If no username is specified, then the root user is assumed, so the above is often shortened to:
su -
or
su
but the two commands above behave differently. 'su <user>' gives the current user the identity of <user> whereas 'su - <user>' gives the current user the identity of <user> together with <user>'s environment that would be obtained by logging in as <user>.
Often a user will become root using just 'su', try to run a command (eg, ifconfig), and get a 'command not found' error. For example:
su Password: ifconfig bash: ifconfig: command not found
The reason is that regular system users and the root user have different PATH environment variables. When you type a Linux command, the shell will search the user's PATH to try to locate the command to run. It starts searching each directory on the PATH until a match is found.
Often when a person reports a problem, in IRC or otherwise, they are referred to this page. In debugging WHY a given binary cannot be seen, it is helpful to view the currently effective PATH with: echo $PATH
Commands for regular users are mostly located in /usr/bin, and /bin and occasionally /usr/local/bin -- the /usr/local/* path prefix is not used for packaging by default upstream. However, root commands are mostly located in /usr/sbin, and /sbin and occasionally /usr/local/sbin As such, root's PATH reflects this.
When you become root by using 'su -', you also adopt root's PATH whereas using just 'su' retains the original user's PATH, hence why becoming root using just 'su' and trying to run a command located in /usr/local/sbin, /usr/sbin, or /sbin results in a 'command not found' error. For a more detailed explanation, see the bash manual page (man bash), particularly the section on INVOCATION and login shells.
So you either need to specify the full PATH to the command if you just used 'su' (eg, /sbin/ifconfig) or use 'su -' when becoming root.
2. Using sudo
You don't need to be root every time you want to run some specific administrative tasks. Thanks to sudo, you can run some or every command as root. Once sudo is installed (package name: sudo), you can configure it by running 'visudo' as root. Basically, it runs $EDITOR (vim as default) on /etc/sudoers, but it is not recommended to do it manually. If you are on a desktop computer, you will want to be able to do almost everything.
So, the quick and dirty way to use sudo would be to add at the end of the sudoers file :
bob ALL=(ALL) ALL
where bob is the name of the user. Save (press escape, then type ZZ), and you are ready to go. Log in as bob, and run for example:
$sudo yum update
sudo will ask for a password. This password is bob's password, and not root's password, so be careful when you give rights to a user with sudo.
But sudo can do more. We can allow a user or group of users to run only one command, or a group of commands. Let's go back to our sudoers file (which is, by the way, well commented on CentOS 5). Let's start with bob and alice, members of a group named admin. If we want all users of the "admin" group to be able to run every command as root, we can modify our example:
%admin ALL=(ALL) ALL
bob can still do his stuff, and alice is now allowed to run sudo, with the same rights, with her password. If bob and alice are not in the same group, we can define a user alias in the sudoers file:
User_Alias ADMINS = alice, bob
here we define an alias named ADMINS, with alice and bob as members.
However, we don't want alice and bob to run every command as root, we want them to run only updatedb. Let's define a command alias:
Cmnd_Alias LOCATE = /usr/sbin/updatedb
But it's not enough! We need to tell sudo the users defined in ADMINS can run the commands defined in LOCATE. To do this, we replace the line with "%admin" with this line:
ADMINS ALL = LOCATE
it means that users of alias ADMINS can run ALL the commands in the LOCATE alias.
At this time, /etc/sudoers looks like this:
User_Alias ADMINS = alice, bob Cmnd_Alias LOCATE = /usr/bin/updatedb ADMINS ALL = LOCATE
alice and bob should be able to run updatedb as root, by giving their password.
If we replace the last line of the file with:
ADMINS ALL = NOPASSWD: LOCATE
alice and bob can run "sudo updatedb" without entering a password.
It is possible to add more commands in a command alias and more aliases in the rule. For example, we can create an alias named NETWORKING containing some networking commands like ifconfig, route or iwconfig:
Cmnd_Alias NETWORKING = /sbin/route, /sbin/ifconfig, /bin/ping, /sbin/dhclient, /usr/bin/net, /sbin/iptables,
/usr/bin/rfcomm, /usr/bin/wvdial, /sbin/iwconfig, /sbin/mii-toolLet's add this to our /etc/sudoers file (with visudo!), and give it access to our ADMINS group of users, the /etc/sudoers now looks like this:
User_Alias ADMINS = alice, bob
Cmnd_Alias LOCATE = /usr/bin/updatedb
Cmnd_Alias NETWORKING = /sbin/route, /sbin/ifconfig, /bin/ping, /sbin/dhclient, /usr/bin/net, /sbin/iptables,
/usr/bin/rfcomm, /usr/bin/wvdial, /sbin/iwconfig, /sbin/mii-tool
ADMINS ALL = LOCATE, NETWORKING A little try: log in as alice (or bob), and type:
$ping -c 10 -i 0 localhost
the answer should come quickly:
PING localhost.localdomain (127.0.0.1) 56(84) bytes of data. ping: cannot flood; minimal interval, allowed for user, is 200ms
Now, let's sudo it:
$sudo ping -c 10 -i 0 localhost PING localhost.localdomain (127.0.0.1) 56(84) bytes of data. 64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 ttl=64 time=0.049 ms 64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=2 ttl=64 time=0.034 ms 64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=3 ttl=64 time=0.021 ms 64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=4 ttl=64 time=0.030 ms 64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=5 ttl=64 time=0.017 ms 64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=6 ttl=64 time=0.016 ms 64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=7 ttl=64 time=0.016 ms 64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=8 ttl=64 time=0.016 ms 64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=9 ttl=64 time=0.016 ms 64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=10 ttl=64 time=0.016 ms --- localhost.localdomain ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 1ms rtt min/avg/max/mdev = 0.016/0.023/0.049/0.010 ms, ipg/ewma 0.187/0.028 ms
sudo is often used to give certain users partial access to privileged commands so that they can perform limited administrative tasks. One nice feature about sudo is that all sudo commands are logged in /var/log/secure. The above example will write this line in the log:
Apr 18 11:23:17 localhost sudo: bob : TTY=pts/0 ; PWD=/home/bob ; USER=root ; COMMAND=/bin/ping -c 10 -i 0 localhost
That's it. Now never forget, when using sudo: "with great power comes great responsibility".
2.1. Sudo shell
If you have sufficient rights configured in sudoers you can also open a root shell by using
sudo -i
3. Graphical helpers
3.1. GNOME
To do...
3.2. KDE
The 'Run Command...' option on the KDE Menu has the facility (under Options) to run a command or application as a different user by supplying that users credentials. Users who are less confident at the command line may like to consider this as an alternative GUI-based method for tasks that require root privileges.
4. consolehelper
consolehelper is a wrapper for running GUI applications. When it starts, it checks configuration of PAM for the desired application. This means that we can authenticate user with all installed PAM modules. The basic method is to ask for a password, but if we have proper hardware, we can also authenticate using smartcards, tokens, fingerprints, etc. Configuration of PAM is beyond scope of this document (see PAM Administrator's Guide), so we will only show how to configure it when we want consolehelper to run an application as root and request the root password.
As an example, let's configure /usr/bin/xterm to launch as root.
First, because we also want to retain the ability to run xterm as a normal user, we create a symbolic link named /usr/bin/xterm-root to /usr/sbin/consolehelper:
ln -s /usr/sbin/consolehelper /usr/bin/xterm-root
Now to configure pam - create the file /etc/pam.d/xterm-root:
#%PAM-1.0 auth include config-util account include config-util session include config-util
Finally, configure consolehelper to run /usr/bin/xterm as the root user when started as 'xterm-root'. Create the file /etc/security/console.apps/xterm-root:
USER=root PROGRAM=/usr/bin/xterm
That's it. Run 'xterm-root' (from the command line or from a .desktop file), enter the root password and enyoy. If you get an error: "Xlib: connection to ":0.0" refused by server", run 'xhost local:root' first or add the following line to the file /etc/security/console.apps/xterm-root
SESSION=true
Be sure that the line ends with the new line character.