As previously mentioned, the protection offered by Linux when working as a normal user is a definite advantage. Certainly , working as root all the time is one of the worst habits that a novice Linux user can develop. For example, suppose you re working as the root user, and you re cleaning up some unwanted files in your home directory, so you want to execute the following command:
# rm rf /home/eziodm/tmp/redundant
Now, consider what happens if you accidentally insert a space character, like this:
# rm rf /home /eziodm/tmp/redundant
Please don t try this out for yourself! The extra space character is almost invisible, but it completely changes the meaning of the command. The first of these commands will attempt to delete only the directory /home/eziodm/tmp/redundant and its contents. But the second command will attempt to seek out and destroy the contents of every home directory on the system!
If you re working as root, there s no protection ”root is allowed to delete these directories, and they ll be wiped out in an instant.
You can protect yourself from accidents like this by working as a normal user. Normal users are prevented from deleting such important directories, and this is what happens when you try:
$ rm rf /home /eziodm/rmp/redundant rm: cannot remove '/home': Permission denied
So, the message is clear: use the root account only when it is really necessary. This generally applied policy has so far prevented viruses from spreading wildly in Linux (and UNIX in general). It s impossible for an ordinary user to infect an executable in the /bin directory, quite simply because ordinary users don t have Write access to those files.
In addition, it s possible to protect personal files and directories by disabling write permissions to prevent accidental deletion.
You don t need the root account for those daily tasks such as surfing the net, and you won t miss root s authority. Most of the time, there is simply no advantage in working as root. Naturally, there are times when administration rights are required ”for example, when doing (but not limited to) any of the following:
Adding new users
Changing a forgotten password
Connecting to the Internet
Setting up a local area network connection
Formatting a floppy disk
Fedora Core comes with an excellent set of tools to perform these tasks graphically, and as you ve seen, the system asks you to enter the root password when necessary, so there s no need to be root all the time.
Here are some other tips to improve your normal user experience.
Thanks to technologies such as USB, FireWire, and PCMCIA (or PC Card) devices, you have several removable storage media to plug into your computer. In Linux, plugging these devices in can be a tedious job because each device must be mounted, and mounting a device requires administration privileges.
The solution is to update /etc/fstab once and for all as root with the correct information. After you ve done this, normal users will be able to mount removable (or fixed) media, either graphically or via the command line.
Suppose you have a CompactFlash card containing pictures taken with a digital camera. Once inserted, Fedora Core supports this medium, which is considered just as if it were an ordinary hard disk.
If you don t know the name of the device associated to your removable media, try to plug it in and have a look at the system logs. To do this, select Main Menu>System Tools>System Logs, or type system-logviewer from a terminal window. Authenticate if necessary, and then choose System Log and insert your card. You should see something like that shown in Figure 7-22.
You can see the same lines in a root terminal by using the following command:
# tail -f /var/log/messages
In this output, you can tell that the device has been recognized as an IDE disk, hde , with only one partition ( hde1 ). Thus, /dev/hde1 is the device you want to mount.
Now you have to choose a mount point in the filesystem. Any empty directory, for example /mnt/flash, is an appropriate mount point. You can create /mnt/flash from the file manager, or from a root shell using the following command:
# mkdir /mnt/flash
The final step to make this device available to normal users is to edit the file /etc/fstab . This file contains a list of mountable devices and relative options. As root, open /etc/fstab using a text editor such as gedit . Add the following (highlighted) line at the end of the file:
... /dev/cdrom /mnt/cdrom udf,iso9660 noauto,owner,kudzu,ro 0 0 /dev/fd0 /mnt/floppy auto noauto,owner,kudzu 0 0 /dev/hde1 /mnt/flash auto noauto,user,kudzu 0 0
This is how to read the line:
The first field ( /dev/hde1 ) is the device to be mounted.
The second field ( /mnt/flash ) is the mount point.
The third field ( auto ) will try to detect automatically the filesystem type on the device, for example vfat (very likely) or ext3 .
In the fourth field, noauto prevents the device from being mounted automatically when the system is started. Also, owner is the crucial option: it is this setting that allows normal users to mount the device. Note that for this to work, /mnt/flash or your chosen mount point must be mentioned in /etc/security/console.perms .
The rest of the line is not relevant to our example and can be ignored. You can find out more with man fstab .
Now the CompactFlash card can be mounted and unmounted by normal users without root s intervention. To test this out, log in as a normal user and select Main Menu>System Tools>Disk Management. The User Mount Tool dialog box appears with the newly added device, as shown in Figure 7-23.
At this point, you can mount or unmount it by pressing the appropriate button and browsing its contents through the file manager.
You can try from a normal user terminal, as well:
$ mount /mnt/flash $ ls -l /mnt/flash total 2 drwxrwxr-x 4 eziodm eziodm 2048 Nov 9 12:35 dcim $ umount /mnt/flash
As an extra bonus, files stored in the CompactFlash card are owned by the user who mounted the device.
We ve already used the switch user command quite extensively to change the user account context within a terminal window. If you need to perform a lot of administrative work, it makes sense to open a terminal window, execute su - in it (to log in as root), and then keep that window open for admin tasks, for as long as you need it. Every time you need to run a command as root, just type it into that window, while you do all your other non-admin work in another window, as a normal user.
If you take this approach, it helps if you have some way to make the root shell terminal window visually distinct from the non-root shell window. This is effective, and very easy ”you can create a special root shell terminal on your desktop, and give it distinctive features, such as a different title and color scheme.
First of all, while using a normal account, you need to create a new terminal profile called root . Here you ll give it a red background and a permanent root shell title.
Open a terminal window (choose Main Menu>System Tools>Terminal).
From the Edit menu, choose Profiles. . ., and then click the New button and type root as the new profile name (see Figure 7-24).
Press Create to confirm.
Now, in the Editing Profiles window, you can use your creativity to personalize the window used for root shells . For example, you can change the initial title to root shell, and set the color scheme to white-on-red, as shown in Figures 7-25 and 7-26.
Whatever you decide to do, you must select the Run a custom command instead of my shell checkbox in the Title and Command tab, and the command must be su - . It is this that ensures that, whenever this profile is activated in the terminal, Linux will execute su - , and not your habitual shell.
By choosing a colored background, you create a root shell window that is clearly distinct from the others. Moreover, the title of this window will always contain the phrase root shell, even if the application changes it.
Be sure to select Default as the Profile used when launching a new terminal in the Profiles window, otherwise every new terminal you open might be a root shell.
If you don t want to create a special launcher on your desktop or bottom panel, that s it: whenever you open a terminal window, you can choose File>Open Terminal or File>Open Tab and select the root profile instead of Default. Naturally, before having access to the root shell, you ll need to type the root password. (No matter how acquainted you get with your Linux system, it will never trust you completely).
If you want to create a launcher (that is, a personalized icon), click with the right mouse button on the desktop background and choose Create Launcher from the menu that pops up. The Create Launcher dialog box appears, as shown in Figure 7-27.
Fill in the window that appears as shown. It s important to get the spacing and double-hyphen right in the command line:
There is no need to go to the Advanced tab. The key here is that you start a new gnome-terminal with the root profile that you ve just created. Therefore, this window will be different than the others.
When you press OK, a new icon will be created on the desktop.
Whenever you double-click the icon, a terminal window appears with the title and color scheme that you specified in Step 3 (the example in Figure 7-28 has white text on a red background). You ll need to type the root password. Once you re authenticated as root, you will be able to use this terminal to issue root commands.
You can also drag the icon on the bottom panel so that it is always available. Be careful and administer your powers wisely.
There are times when you execute the same administrative commands over and over again, and typing the root password becomes irritating . Other times, you trust some users to execute specific administrative tasks (for example, installing new software), and yet you don t want them to have the root password. These circumstances are ideal for the sudo command.
With sudo , you can decide which commands can be executed as root even when typed from an unprivileged shell. As a security measure, you can decide if the user has to type his own password before executing the command or if execution will take place right away. Moreover, you have the power to decide which parameters are allowed during command execution and from which hosts .
Configuring sudo means editing the /etc/ sudoers file. It may appear difficult at first, and the output of man sudoers certainly looks awkward . However, the typical use scenarios are quite straightforward. First of all, /etc/sudoers should be properly locked before editing; therefore, it should always be edited through the visudo command. If you re not comfortable with vi , you can use a different editor by typing EDITOR=gedit visudo instead.
Once in the file, each line represents a different directive, and lines beginning with # are treated as comments and ignored. To allow eziodm to execute any command with root privileges, from any host and without typing the user s password, you can add a line like this:
eziodm ALL= NOPASSWD: ALL
This is how to read the line:
The user account name is eziodm. You can specify several users in a row by separating them with commas, and you can specify groups instead of individual users by using the % prefix. For example, %authors would identify every user account belonging to the authors group .
The first ALL indicates that the line is valid for every host. It could be a comma-separated list of computers (their hostname, or their IP address) on which this specification applies.
NOPASSWD followed by a colon means that sudo will not prompt for the user s password before executing the command.
The second ALL means that eziodm is allowed to execute any command as root. It can be a comma-separated list of commands, preferably with their full path and parameters, if any.
Allowing a user to execute any command without having to type the root password poses several security risks, especially on a shared computer, and it somewhat eliminates the distinction between root and non-root accounts. Here is a second and more restrictive example:
%authors ALL= /usr/bin/make install, /usr/bin/make uninstall
This means that any member of the authors group can execute either /usr/bin/make install or /usr/bin/make uninstall as root, but nothing else. NOPASSWD is missing, which means that sudo will prompt the user for the account s password before proceeding. Note that trying to execute /usr/bin/make alone will fail, and the same will apply for other programs called make located in a different path.
After deciding what goes into /etc/sudoers , the only thing that nonprivileged accounts have to do to execute a command as root is to type sudo right before it. In the following example, the user eziodm types id and sudo id , with two very different results:
$ id uid=500(eziodm) gid=500(eziodm) groups=500(eziodm),504(authors) $ sudo id uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
Naturally, this works because eziodm is allowed to execute any command as root.
If you need to compile software, it s usually sufficient to compile it as a normal user. Any well-behaved piece of software that requires compilation by a root user should warn you of such a requirement. The advice generally offered when extracting and compiling tarballs is to do so within the context of a normal account.
Extracting and compiling from within a normal (non-root) account is also a good security measure. For example, extracting from an archive from within the root account can get you into problems if the archive contains absolute paths instead of relative ones. Consider a tarball that contains a file called /etc/passwd : if you extract it as root, you could be in serious trouble because it will overwrite your user account file. But, if you extract from the safety of a normal user, you re using an account that is not allowed to overwrite the file, so you re protected from such disasters.
Better yet, you can extract and compile software with a non-root, non-personal account ”then you won t even risk the possibility of messing up your home directory.
Immediately before the compiling phase, most modern programs require you to run a configure script. If this is the case (you can almost always find a README or INSTALL file or equivalent to get instructions from), installing the program with a non-root account becomes quite easy. Just run the script with the --prefix option, like this:
$ tar xzvf program_name-1.0.tar.gz $ cd program_name-1.0 $ ./configure --prefix=$HOME/software/program_name-1.0 $ make $ make install
If the program is well behaved, it will compile itself knowing that the installation directory is different than the default, typically /usr/local , /usr , or /opt . This allows you to install the necessary files to a place that you can write to.
If the program doesn t have a configure script, the solution may not be straightforward. In this case, carefully read the documentation that is included with the package ( INSTALL and README files are good starting points) and, if all else fails, ask around or even contact the original developer.
Finally, we come to the first execution of the much sought after program.
Never run newly installed and unknown software as root!
This precaution is especially important if you haven t read the source code of the program and you re not certain about its features. At worst, you might damage your operating system installation, either by accidentally misusing the program or because the software you run has not been carefully written. In some extreme cases, it could even happen that the software you downloaded is not the one you wanted, or it will not behave as advertised.
To test-drive newly installed software, you can create a special user called swtest, for example, and switch to that account every time you run a new program for the first time. You ll have a chance to see the program in action, and possibly check swtest s home directory for added configuration files.