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-tool
Let'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 -s
or
sudo -i
The
later works only on CentOS 5. if used as sudo -s you will get a shell
running as root with the environment of the calling user. So be very
careful as this will create or modify files as root but $HOME is set to
the home directory of the calling user.
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=trueBe sure that the line ends with the new line character.
No comments:
Post a Comment