SDB:Login as root

Jump to: navigation, search


In Unix/Linux systems there is a special user for system administration. This is the user with the uid of 0 and the username root. It is also known as 'superuser'. In daily life it is simply called: root. Root can do anything and everything, hence any mistakes done as root can hose a system. Also, when an unauthorized person becomes root, you are finished.

An original quote from a client, that should serve as warning:

... now an accident happened to me, because I've worked as root. With the
hope of getting any sound, I have typed "ls > /dev/hdb2" instead of
"/dev/dsp" by mistake - unfortunately, /dev/hdb2 is my root partition.

Remark: /dev/hdb2 was his root partition. But, along with malicious glee, we have the deepest sympathy too ;-)

Years of experience in Unix and Linux based systems have led to the conclusion that it is not safe:

  • to do 'normal' work on a system as root (too much risk to do something evil by chance and severe pollution of the system by mixing user data and system data) and only to become root when really needed;
  • to login directly as root, particularly when using a network (danger of sniffing), there are some exceptions to this rule as we will explain later.


We will look into how to observe these rules in openSUSE.

Do not use root for normal work

openSUSE helps you

During installation you are asked to add at least one normal user to the user database. This is the one you should use for your normal work, like or logging in into the GUI (e.g. KDE or Gnome) and handling mail, playing music, surfing the net, and etc. We will call this userid: happy, to represent you as the happy openSUSE user.

The ability to log into the GUI as root by clicking on a listed user is not easily available, by design. You will not be surprised when we tell you not to change this.

What else can be done

When you have more people who use the system (like your husband, children) give each of them a userid. They will then have their own space on disk not touched by others, so they can choose their own desktop manager, wallpaper, etc. While this recommendation is only remotely related to our root user problem, it shows the difference of 'normal' users and root to advantage. There may be many normal users, but there is only one root. And the knowledge of the password of root must be restricted! The case that there is but one 'normal' user (happy) is a special case of multi-user Linux. And it leads to the following recommendation.

Consider installing a user for the tasks and data of the systems administrator. Let us call this user: admin (as an example). Now you can do and store things in your role as systems administrator, which do not need do be done as root, separate from the things you do and store as happy.

By the way, you can introduce users using YaST > Security and Users > Users Management.

Over the network

Before we go on, first a word about the network. As protocols as Telnet, Rsh, and Rlogin are considered very dangerous to use in today's networks even for normal usage, never use such protocols when you by any means send the root password over it. Always use secure protocols like ssh.

Do not login directly as root

All the actions to become root will ask you for the root password. This is not only to prevent other people to become root, but it also tells you to be especially careful in what you are going to do.

We already talked about login in as root in the GUI. This is not easily done in openSUSE, and rightly so. This does not imply that we cannot use GUI oriented programs to manage our systems even if they require root privileges.

Programs that handle this problem themselves

An example is YaST. When YaST is started it sees that it is not running as root, asks for the root password, and will continue as root. When all of YaST finishes there are no more root processes left behind.

Some programs have special options that generate this sort of action like:

  • konsole --type su will start the terminal emulation program Konsole asking for the root password in the terminal window, it will also use a different colored background to remind you of the root status;
  • konqueror --profile filemanagement will ask for the root pasword and open a file management window.

There is no need to learn these examples by heart, because when you go to the KDE Menu > System > Terminal > Terminal Program (in systen management mode) this will let loose the first example, and likewise KDE Menu > File Management > File Manager (in system management mode) for the second example.

Start any GUI program by using kdesu/gnomesu

You probably know you can execute a command by either KDE Menu > Execute a Command, or by the key-combination Alt-F2. Start your command with kdesu followed by the command (name of the program) you want to execute as root e.g.: kdesu xterm will start the (a bit outdated) terminal emulator of that name, but beware: what you type there you type that as root! The equivalent command for Gnome is gnomesu.

It is probably not a good idea to start Firefox this way and then go surfing and downloading throughout the Internet. So know what and why you are running as root.

Execute a command as root during a terminal session

It is very common in Linux to use the command line, especially for root. As mentioned above you could start a CLI (Command Line Interface) terminal emulator (konsole, xterm) directly as root, but when you are not typing statements that require root privilege all the time it is better to start the terminal emulator as admin/happy and restrict root usage only to the required statements. Use the sudo statement for this e.g.

sudo /etc/rc.d/apache2 restart

After the Apache restart is finished (you will normally see any output generated during this action) you are again admin/happy. For editing the fstab you could use sudo vi /etc/fstab. But kdesu kwrite /etc/fstab is also an option when that is your favorite editor.

Execute a command which has a GUI as root during a terminal session

For starting a GUI program as root you need access to the DISPLAY which is owned by the user you're logged-in as. The sudo xeyes command gives: unable to open Display: To resolve this you can start sudo using -E option to keep the environment preserved. To make it permanent follow the following steps: sudo /usr/sbin/visudo find the line that says Defaults env_keep= " LANG LC_ADDRESS ... add DISPLAY and XAUTHORITY to this list. The beginning of the line now looks like this:Defaults env_keep = "DISPLAY XAUTHORITY LANG LC_ADDRESS ... Save the file and now you can type sudo xeyes without the need of the -E option.

A longer terminal session as root

When longer root access is needed use the su command. A new shell is started with root privileges. The usage of the option - (or -l or --login) is strongly recommended because it starts the shell for root as a login shell. This means that all initializations run during a normal login is done and among other things this will give you the correct PATH variable. When not doing this you will have the PATH variable of happy/admin which may contain unexpected directories which may contain dangerous executables. Most notorious is the directory . (your working directory). When a normal user creates, for example, a script with the name ls containing

Warning: The following code is an example of what not to do. If you run the code below, it will destroy your system, deleting everything. The code below is comparable to deltree C:\
cd /
rm -rf *

in /tmp/ or in his/her home directory, root can erase the complete system unintentionally. Even when the . is the last directory in the PATH one is not safe from typing errors calling a local program unintentionally (instead of lsi -a, la, for example). So to become root for a longer session:

happy@system:~> su -
system:~ #

Mind the different prompt (which even shows red in some terminal emulators). To end your session as root:

system:~ # exit

The real console


The reader should understand that this section was originally created in the days of SysVint, prior to systemd. Although the Linux subsystem has changed radically with systemd, as long as systemd supports most legacy concepts, this section is still largely valid, but may not always be so and the reader should be watchful of exceptions. For the most part, tty1 and tty7 (alt-ctl-f1 and alt-ctl-f7 plus adding the fn key on some machines) can still be expected most of the time, but might not always be so, and now new displays will likely be invoked on tty2, tty3, etc instead of tty8, tty9, etc.The following blog by Lennart Poettering explains this.


The real console of your system is the keyboard screen combination you know already because it is also used for your GUI. To allow for this multiple use there are several 'logical screens' available. These can be reached by the key-combinations Ctrl-Alt-Fn. Your GUI is normally at Ctrl-ALt-F7. You can have a second (and more) GUI logins at the same time, to be found at Ctrl-Alt-F8, etc. The real console is at Ctrl-Alt-F1. When you try this key-combination for the first time after a boot you will see the last lines of output of that boot and a terminal login prompt. The same applies as for a terminal emulation (login as admin/happy and use sudo and/or su though NOT kdesu or gnomesu.

There are more terminal logins waiting for you at Ctrl-Alt F2 ... Ctrl-Alt-F6, but they are less nice to see and almost nobody uses them (maybe one of them when number 1 hangs).

As the real console is very difficult to sniff from, you may login on this one as root directly. This may even be necessary when your /home is unreachable (when it is on a separate partition, which is a good thing, it may be unmounted either because of a problem or because it is needed during e.g. an update/install). You can not login as a normal user then. But root's home directory is not in /home, it is in /. This is one of the reasons why this is done.


  • Practical UNIX Security by Simson Garfinkel and Gene Spafford (O'Reilly Serie, ISBN 0-937175-72-2)
  • Essential System Administration by Æleen Frisch (O'Reilly Serie, ISBN 1-56592-127-5)
  • Computer Security Basics by Deborah Russell and G.T. Gangemi Sr . (O'Reilly Serie, ISBN 0-937175-71-4)


SDB:root cannot execute certain programs <keyword>root,login</keyword>