"The Linux Gazette...making Linux just a little more fun!"

Multiple Root Accounts: Delegation

From R Dalton on Wed, 13 Oct 1999

Hello Answer Guy

I'm wondering if it is possible to setup multiple root accounts on a linux system for more than one unix admin to monitor a system ?

If this is possible how ? also can they have different root directories ?

Thanks. R Dalton

It is possible to have multiple accounts with 'root' privileges. The easiest way is to edit the /etc/passwd file (using 'vipw') and make extra copies of the line that starts with "root" (the root account entry).

Then you edit the login name field (the first one), and the full name (GECOS) field, the home directory field, and the shell field. Then you issue the 'passwd' command to set each of the initial passwords for each of these.

Example (excerpt from an /etc/passwd file):

root:x:0:0:root:/root:/bin/bash
toor:x:0:0:Alternative Root Acct:/root:/bin/bash
ruut:x:0:0:Cracker Jack:/root:usr/bin/pdksh
jonroot:x:0:0:Jon Doe:/home/jon/root:/bin/bash
tomroot:x:0:0:Tom Boote:/home/tom/root:/bin/bash
jillroot:x:0:0:Jill Tedd:/home/jill/root:/bin/tcsh
jimd:x:500:123:Jim Dennis:/home/jimd:/bin/bash

In this example I have the customary root account followed by 'toor' ("root" backwards) and 'ruut' (punny spelling of "root"). Then I have a set of root equivalent accounts for Jon, Tom, and Jill.

I've followed those entries with a token "normal" user account for comparison. The only important detail is that the 3rd field on the root equivalent accounts is set to '0' while all non-root accounts have other numbers (UIDs).

All kernel and filesystem data structures that store and manipulate ownership (of files, processes, etc) and check permissions use the numeric UID. The /etc/passwd file is the primary way to map names to UIDs and vice versa.

Note that this works in any form of UNIX. However, it is not necessarily the best way to do things. Some programs will do get a login name by looking up the UID. When we have non-unique UIDs, we can confuse those programs (of course, you probably shouldn't be running those programs as 'root' anyway).

There are other potential problems with this strategy. Obviously having more people and more passwords that give the same level of access increases the risk that unauthorized people will guess or steal those passwords, or trick one of the admins into doing "bad things" (social engineering). Also this mechanism provides no tracking of who did what. There is no way to distinquish between what jillroot and tomroot did (since they have the same UID --- which is all the system uses for marking file ownership and checking privileges).

A better way for most situations is to install ' sudo'

The sudo package allows you to selectively give access to specific users and groups, allowing them to execute specific programs and with specific options. The users run the 'sudo' command, which prompts them for their own (normal user account) password.

In your case you might just start by installing sudo and configuring it to allow access to a command shell (/bin/sh and/or /bin/bash). That's pretty simple. It effectively gives you the benefits of the multiple account entries (though it doesn't set up separate home directories). One advantage is that it does logging of who used which sudo commands at what time.

(Obviously a 'root' user can edit the local syslog entries and can stop, restart, and resplace the local syslogd daemon to "cover his tracks" --- 'sudo' to root access doesn't protect you from unreasonable expectations. But the logging can help a bit).

As you more clearly define the precise operations that you need to delegate; you can edit your /etc/sudoers file to more precisely limit your users and groups to those specific programs and scripts that they need.

The sudoers file is relatively to understand.

The only confusing part is that its entries refer to network hosts and "netgroups" (a Sun NIS concept). This is intended to allow sites to create a single /etc/sudoers file and distribute that to all of their systems. The reason I found this confusing when I first installed 'sudo' is that 'sudo' itself doesn't providing any networking or distribution mechanism (and the man page doesn't actually explain why they put these hostname references there or how you'd use them). It assumes that the sysadmins using the package will want to create a uniform sudoers file and know how to do it (through rdist, ssh/scp, rsync, etc).

cfengine is another package you might want to consider. It has nothing to do with authority delegation (giving out root privileges to more users), but may be useful for automating your system monitoring and configuration tasks.

cfengine is a host configuration utility. It implements a language to describe certain sorts of system administration policies and corrective actions. It's an intriguing concept that I've only played with a little bit. However, it is gaining popularity in sysadmin circles (along with the healthy respect that one reserves for a loaded firearm --- one mistake in a cfengine script can make thousands of changes on hundreds of hosts).

Copyright © 1999, James T. Dennis
Published in The Linux Gazette Issue 48 December 1999

HTML transformation by Heather Stern of Starshine Technical Services, https://www.starshine.org/

					1	2	3	5
				5	6	7	8	9
10	11	12	13	14	15	16	17	18
19	20	21	22	23	24	25	26	27
28	29	30	31	32	33	34	35	36
37	38	39	40	41	42	43	44	45
46	47	48	49	50	51	52	53	54
55			56			57