Is There a Good Way to Grant root Permissions on a Limited Basis?
Yes. sudo is a program that allows a given user to execute commands as though they were a user other than themselves (including root). This allows the system administrator to delegate the use of some programs that would otherwise only be executable by root.
When installed, the sudo program must have its SUID (set user id) bit set. Having the SUID bit set means that the Linux kernel will trust sudo to execute programs as root and to change a program’s UID (user id) during runtime.
The configuration file for sudo is /etc/sudoers. In short, it associates users with privileges. A privilege can be defined on three different levels. It describes what you can execute, as which users, and on what hosts. On top of that, users and privileges may also be aggregated into groups.
Due to the fact that the syntax can be tricky at times, it is strongly recommended that visudo be used to edit this file. visudo provides integrity checks that ensure that /etc/sudoers is never in an invalid state.
That having been said, let’s start with a simple example. The most generous level of privileges that could be bestowed is:
The word ALL is a special, context-sensitive alias that can mean three different things, depending on what part of a privilege you’re talking about. The first ALL means that this rule applies to any and all hosts. The second ALL (after the “=” and enclosed in parentheses) means that this user may pose as anyone when running a command. The third ALL means that this user may execute any command. Thus, this definition would allow the user q to execute any command, as any user, on any server. Anyone with privileges like this is practically root.
Fortunately, privileges can be bestowed at a finer level. One of the best features of sudo is its capacity to define aliases such that privileges and users can be aggregated into logically coherent groups. The four directives used to perform this are User_Alias, Host_Alias, Cmnd_Alias, and Runas_Alias.
The syntax of these grouping directives is very straightforward and consists of three distinct parts. The first column contains a directive. The second column contains the name of the new group. Finally, this is followed by an “=” and a list of items that are appropriate for this directive. Figure One shows an example.
Figure One: Example of Grouping Directive
User_Alias SYSADMINS = q, jeremy, joel
User_Alias WEBMASTERS = hayden, tom, %webmonkeys
Figure One defines SYSADMINS as being the group of users composed of q, jeremy, and joel. This also puts user hayden, user tom, and the group webmonkeys into an alias known as WEBMASTERS. Groups are differentiated from user names by placing a “%” in front of the name.
This allows one to hierarchically organize rules. Suppose that you want to let the SYSADMINS have free reign over system management. You also want to let the WEBMASTERS perform simple administrative tasks on the home LAN but only database related tasks on the external servers. This could be defined as seen in Figure Two.
Figure Two: More Sophisticated Use of Grouping Directives
Cmnd_Alias BASICADMIN = /bin/kill, /bin/rm, /bin/mv
Cmnd_Alias REBOOT = /sbin/reboot
Runas_Alias DATABASE = mysql, postgresql, oracle
Host_Alias HOMELAN = 192.168.0.0/255.255.255.0
Host_Alias EXTRANET = 10.10.0.0/24
SYSADMINS ALL = (ALL) ALL
WEBMASTERS HOMELAN = (ALL) BASICADMIN : EXTRANET = (DATABASE) ALL
From this example you can also see how it’s possible to stack multiple permission structures onto a single configuration line.
It’s also possible to use sudo in conjunction with applications like su to give a similar result. For example, a configuration line such as:
rob ALL = /bin/su musicplayer
would allow the user rob to only su to musicplayer.
This is just an introduction to some common /etc/sudoersidioms. Basically, sudo is a highly configurable and extremely useful tool for defining user privileges. If you’re interested in learning more, be sure to check out the man pages for sudo, visudo, and sudoers.
How Do I Force Package Installs?
Let me make it very clear from the start: forcing package installations is generally not cool. Packaging systems exist for a very good reason — to bring sanity to the program installation process. Nearly all packaging systems use some form of dependency checking to ensure that each program on the system will have everything it needs (in terms of software) to work. This is particularly useful for ensuring that the right versions of the right programs and libraries are installed.
Therefore, to force an installation against a package manager’s will is often a very questionable idea. A package manager’s job is to guarantee perfect system integrity at all times, and the use of force should not be necessary. That’s the theory anyway.
The reality is that nothing is perfect. People make mistakes. A dependency might not be properly defined, or a careless sysadmin might have accidentally overwritten a previously installed package. Who knows what else may go wrong? Unfortunately, package installations fail from time to time.
So, if you’re thinking of forcing a package to install, stop and think. Before doing anything, it’s necessary to determine why an installation is failing. Ignorance is not bliss when it comes to system administration. Use your own knowledge of your system to examine the situation and ensure that a forced installation will be safe. When you’re sure, proceed with caution.
All that said, let’s look at some techniques for forced package installation using dpkg and rpm. (These are the programs responsible for package management in the Debian and Red Hat distributions, respectively).
With dpkg, a summary of the force commands can be found by typing dpkg –force-help. This gives a general overview of what can be overridden. The list is fairly long, but for our purposes, just looking at a few of them will suffice.
First, examine Figure Three to see if you can identify what the problem is. Fortunately, the messages displayed by dpkg are usually very informative.
Figure Three: dpkg Error Messages
dpkg: error processing libroxen-ldapmod (–install):
dependency problems – leaving unconfigured
Errors were encountered while processing:
To ignore a dependency problem like this, type:
dpkg –install –force-depends
This will cause dpkg to display a number of non-fatal warning messages, but the installation of the package will continue unabated. The option –force-depends allows the installation of the package, regardless of whether the prerequisite packages are installed on the system (at least to the best of dpkg‘s knowledge). If the packaging system is to be believed, this application will not work as intended. Perhaps you know better.
Similarly, if you are attempting a forced installation to circumvent a dependency-versioning problem:
dpkg –install –force-
will allow you to continue as planned. Hopefully, the general pattern of these “force” options is becoming apparent.
In rpm, the commands to be issued are fairly similar. The equivalent of the –force-depends option in rpm is the –nodeps option. For example:
rpm -Uvh –nodeps package.rpm
would proceed to install package.rpm without checking to see if any of the packages it requires are installed.
The rpm command has a few other neat installation options, including –replacepkgs, which will allow for the overwriting of any packages that have already been installed, and –replacefiles, which allows for the overwriting of files owned by another package. Another useful option is –oldpackage, which permits the installation of an obsolete package. These let you have it your way with no questions asked — you’re the boss.
Just be sure that you really are in control. Forcing is only a good idea if you’re absolutely sure that your actions will not harm the system. If not, it can be a nightmare to get back to where you were.
Quentin Cregan is a tech and security consultant and sometime student hailing from Australia. He can be reached at firstname.lastname@example.org.