Article Sidebar 1 Sidebar 2 Table 1 dec98.tar

Sidebar: Managing Personal root Accounts

The use of individual root accounts (e.g., rootjs for John Smith's root account), rather than the anonymous real root, is advantageous when sys admins use RCS, and is preferable for these reasons as well:

  • Each person can have their own personal root environment. This is accomplished by either specifying unqiue home directories or by customizing the .profile with a case $LOGNAME statement.

  • It makes it more convenient to determine who did what.

  • Each account can have a separate root shell history (if you use su -rootyou to become root)

  • It will enable you to keep track of who did what edits as root with RCS. (Even though you are really root (uid=0) when you log in, RCS will use your login name to track changes.)

  • It is more secure than sharing the real root password. If necessary, you can disable one user's root access without having to change the password for everyone.

Adding root Accounts

Using vipw, if available, edit the passwd file(s) to add an entry something like this:

root:x:0:1:Super-User:/:/bin/sh
rootjs:x:0:1:Root - John Smith:/:/bin/ksh

When adding additional uid 0 accounts, remember the 8-character limit on the length of UNIX user names. It may be convenient to name the accounts rootxx, where xx are the users initials.

Note that under AIX, users are added using the smit command. smit doesn't allow the addition of multiple password entries with the same user id. I work around this limitation by adding the additional rootyou accounts with other uids. I then edit the /etc/passwd and /etc/security/user file manually to set the uid to 0 and set the user attributes like those of the real root account.

If your system provides a utility such as Solaris' pwck(1M), you can use it to check the passwd file integrity before logging out of your root shell. When adding multiple "uid=0" accounts, make sure to add the additional root accounts after the "normal" one, so that files owned by uid=0 will show root as the owner. (On most systems getpwuid(3), the function commonly used to translate a numeric user id to a user name, will perform a sequential search of the passwd file. Still, some systems, such as Digital UNIX, create a hashed database of passwd file entries to efficiently perform getpwuid(3), so ls(1) might show a user name other than simply root. This is only a small annoyance as long as you put the word root in the names of all "uid=0" accounts.) Also, it's safer to leave the real root as the first line in case the passwd file is somehow corrupted while editing.

Make sure that the GECOS field has a unique "real" name (i.e., more specific than "superuser" or some such thing) so that if anyone sends email using the name from the GECOS field, it will go to the right place. Many sendmails will allow you to send to the user name by the name in this field with underscores in place of spaces (e.g., John_Smith). You would want this email to go to John Smith's normal account. However, if you had accidentally put John Smith in the GECOS field as rootjs' "real" name, email to "John_Smith" would be delivered to rootjs, because that entry would be encountered earlier in the passwd file.

Becoming root using su(1)

The - argument to su(1) causes it to invoke a login shell. This is necessary so the shell startup files (e.g., /etc/profile, .profile) and rc (e.g., /.kshrc) will be sourced - enabling you to customize your root shell environment:

$ su - rootyou
Password:
#
Changing a root Account Password

When changing a root account password, it's important to use your own root account name as the argument to passwd. Otherwise, you will end up changing the real root passwd and confusion will ensue:

# passwd rootyou
New password:
Re-enter new password:
#
Maintaining Shell Startup Files

Common shell startup files, such as /etc/profile and root's .profile should be compatible with Bourne shell syntax, so they will be compatible with all commonly used shells. A similar rule holds true for csh-derived shells and their respective startup files. Here's a sample fragment for root's .profile:

# { Some systems don't set LOGNAME to the login name specified at the
# "login:" or as arg to su(1).  (I.e. sometimes it will be "root" even 
# though another uid=0 username was specified.  Try to fix that here...
case "$LOGNAME" in
root|'')
LOGNAME=`/usr/bin/logname` # set LOGNAME correctly to the real login name
export LOGNAME
;;
esac
# }

case "$LOGNAME" in

you|rootyou) # rootyou uses ksh
LOGNAME=rootyou
export HISTFILE=/.sh_history_${LOGNAME?}
;;

*) # generic root, keep syntax Bourne shell compatible
HISTFILE="/.sh_history_$LOGNAME"
export HISTFILE
;;

esac

Lastly, under some UNIX flavors, I have noticed that the LOGNAME environment variable is not set to the real login name given at the login: prompt or as an argument to su. This problem is exhibited under RedHat Linux with pdksh as the login shell, for example. If after logging in as rootyou, you find that LOGNAME is set to just root, rather than your own personal login name, modify your shell initialization file so that it will be set appropriately. For instance, if your login shell is sh, bash, or ksh, add this line to root's .profile:

LOGNAME=`/usr/bin/logname` # be sure LOGNAME is set correctly to the login name
export LOGNAME

If multiple system administrators maintain these files, it would be a good idea to use RCS.