Programs knowing of "root" - Summary

[John Bossert]

As I promised, here is the summary of responses to the question:
`What programs depend upon the existence of the username "root"?'
I'm considering, for security purposes, replacing the root account
(a known username) with a less common name (keeping uid == 0) and 
need to know the possible side effects.  Thanks to all who responded.

-----------------------

Subject: Re: Programs knowing "root"
From: David C. Stewart <uw-beaver!tektronix!davest>

	There is probably a large contingent of programs which assume
that root is a valid uid 0 account and others which require root to
be the `first' uid 0 account in the passwd file.    One example I
can think of in the first class is /usr/lib/crontab in 4.3 - the name
of the user is listed under whose ownership a line in crontab is
run.  An example in the latter class is sanity scripts which check the
ownership of certain files.

	So long as root is first in the passwd file, other uid 0 accounts
work fine.  For example, here at Tek our group supports over 30 machines,
each of which have their own root passwd and a uid 0 account called
`avatar' which we maintain the passwd on so that we can maintain the
machines.

-----------------------

Subject: Re: Programs knowing "root"
From: uw-beaver!nike!harvard!axiom!drilex!dricej (Craig Jackson)

I'm not sure if this helps or not, but on Zilog machines, root is named
'zeus'.  You might check with them; I'm not sure if they're on the net,
however.  This is a binary-only System III port, so I don't know what
they changed to make it work.

I do know 'root' occurs down in the sendmail.cf file on 4.2.

-----------------------

Subject: Re: Programs knowing "root"
From: fluke!decwrl!mips!dce (David Elliott)

The following commands/files require that an account named "root" exist:

/bin/su
/usr/bin/install
/usr/lib/find/updatedb	(4.3)
/usr/lib/aliases 	(** Could he mean /usr/lib/sendmail? JPB **)

Except for find, none expect that the userid must be 0. You should probably
have "root" exist as an account with userid 0, but you can, as you know,
have as many accounts with userid 0 as you want, with one restriction: in
4.3BSD, the password database code does not force the first entry in the
password file to be the major uid hash. For example, assume I have 4 accounts
for UUCP: uucp, uudecwrl, uuglacier, and uutest, all with the same userid.
Assume that these are found in this order in the password file. In 4.2 and
before and in AT&T Unixes, the command 'ls -l' will always show files owned
by this userid as being owned by 'uucp'. In 4.3, this command will consistently
show one of these, but not necessarily uucp, since the hash on uid is not
the same as the hash on username.

I know this to be true from experience, and it really isn't a big deal.

Oh, the list I gave above was obtained by looking through my product
source release (95% of 4.3BSD, since we don't ship Vax-dependent stuff)
for shell scripts. Su I knew about due to recent heavy work I had to do on
it, and aliases because I had to change it locally. I didn't look at other
C sources, but having gone through most of these 3 times already, I am
pretty sure there aren't more than 1 or two if any.

-----------------------

Subject: Re: Programs knowing "root"
From: uw-beaver!ihnp4!seismo!rutgers!caip!cbmvax!grr (George Robbins)

In System VR1  (at least the Zilog flavor) "root" is compiled into su and init.
The init is a real nut-cruncher, since deleting the "root" entry from
/etc/passwd prevents you from booting up into even single user mode.

The safe thing is two have two entries for "root" in you /etc/passwd file,
the first being the one that the system uses to translate uid 0 to "root",
the second being "root" to satisfy programs that have this hard coded.
The passwords can be identical, or arranged to prevent logins or one or the
other.

This works nicely for system V, but I make no claims about Berkeley.  In the
Zilog case, "zeus" is actually compiled into the programs, but I prefer to
use "root" like any normal unix system.

-----------------------

Subject: Re: Programs knowing root
From: uw-beaver!tektronix!hplabs!ihnp4!ih1ap!sja (Steve Alesch)

Grep(1) for root.  That's what anyone else would do.  Would you really
trust someone elses list, anyway?

BTW, I'm curious why you would want to spend time renaming root.

-----------------------

Subject: Re: Programs knowing "root"
From: fluke!sun!arete!stone

I did this once under System V.1 several years ago.  It was a terrible
mistake in that we couldn't get into single user mode.  After init
starts up, the first thing it does for you is an "su".  Well an su
without arguments is a synonym for "su root".  It was at this time that
I learned the usefullness of keeping spare root partitions around
(we hadn't at the time).  We ended up reloading root.  After that I
had no desire to learn what else might be broken by changing the root
logname, so I left it alone.  Depending on your requirments, you might
just duplicate the uid and gid for root in other logins.  I have
root, rootcsh, and rootksh on my system.

-----------------------

Subject: Re: Programs knowing "root"
From: uw-beaver!tektronix!reed!kab (Kent Black)

BSD4.3 from Xinu comes with two 'roots'; "toor", a.k.a., the Bourne-
Again Superuser, has default /bin/sh, whereas "root" starts with /bin/csh.

I hope this means that NO programs depend on the name!  I've not yet
failed as "toor", but it's only been a month since we brought up 4.3;
certainly something to watch for.

-----------------------

Subject: Re: Programs knowing "root"
From: uw-beaver!tektronix!hplabs!ihnp4!alberta!ncc!lyndon

We run various bits of Convergent Technologies equipment. The /etc/halt
and /etc/shutdown scripts check the invoker by looking at the value
in $LOGNAME, and also by looking at the output of the id command
which looks like this:

uid=200(lyndon) gid=201(staff)

Convergent equipment runs CTIX, which is basically SYS_V.

I remember reading in the internals documentation a very strong warning
not to change the name 'root' to anything else, and to make sure it was
the first entry in the passwd file...

Why would you want to change it?

-----------------------

-- 


	John Bossert

	UUCP: uw-beaver!ssc-vax!bossert
	OLD Internet: ssc-vax!bossert at uw-beaver.ARPA
	NEW Internet: ssc-vax!bossert at uw-beaver.washington.edu