Multiple users w/UID 0

[Shawn Hileman]

I created 3 users and updated UID to 0 in passwd file. Works fine on my hpux 11.0 boxes, but can't su on or telnet to my 10.20 boxes (with new users), gives me 'unknown id', but works fine if login through CDE.

Doesn't seem to be a securetty check or any option I can find in SAM....

Any ideas?

btw, reason for this is we have 3 sa's. Is there a better way to have 3 root type users?

[Volker Borowski]

Hello,
just be very carefull, when you delete one of your add-on users.
Be sure NOT to delete all files belonging to user "ruth", because an "ls -l" check tells you that "ruth" has no files as they are owned by "root" (which is displayed as a first match of /etc/passwd).
You will end up installing a new system if you do, as this delete goes numeric, not alpha-based !
Good reasons to have second "roots" may be, if you like to use another shell. You should never change the "root" shell to other than /sbin/sh, because you might not get access to /usr/bin/ksh if your /usr filesystem is defective. This will lock you out.

Just my 2 cent
Volker

[Rita C Workman]

You can use uid=0, but I would prefer to have folks login as themselves then su to root (and if I've given them root rights...I gave them the password). That way you eliminate the chances of the problem Volker mentioned.

Another 2cents,
/rcw

[Keith Bunge]

A better way to implement this might
be to setup sudo. sudo allows you
to give "normal" user accounts the
ability to run commands as root. You
can find more information about sudo
at:

http://www.courtesan.com/sudo/

As for why you can't log in as those
alternative root users I would look in
/var/adm/syslog/syslog.log to see if
you see any other errors being
generated on login.

[Tim Malnati]

I've used this method for years and has many benefits. It is a good way to have multiple sa's access the box where they can each have their own login id, password, preferred shell, login directory, shell history, etc. Where they already have root priviledges, they don't have a need for the actual root password. So in the event that one of the sa's leaves the organization, you only need to lock out their account instead of immediately changing every root password on every machine. The only password gotcha I'm aware of is the CDE screen saver password where it wants actual root instead. Another thing I do is make these logins part of the 'adm' group instead of 'sys' . This makes it easier to determine what was done manually vs a cron or daemon. There is one important thing though. A more restrictive umask than root's can be problematic with swinstall. It seems that the fileset installs have been setup with root's default umask in mind instead of overriding things to what they should be. The same thing happens if root's umask is adjusted so I consider it an swinstall issue.

[Shawn Hileman]

Tim hit my reason for doing this right on the head. Another glich is when you change passwd. if you don't specify the userid, it wants to change root instead of the pseudo-root.

My only problem is with my 10.20 version boxes and the unknown-id error whether i'm telneting to them or simply su-ing from another user...anybody have any help on why I can't, but can come in using CDE emulator (exceed)?

[Victor BERRIDGE]

Hi Richard,
I when implement many UID 0 accounts (max 4) is to deny direct login by using /etc/securetty, create almost ordinary accounts except for primary group which is bin, so these users can modify and access where others cant without doing an su - user-root-account, in each root account .profile I log who and from where(IP) he did the su, but each user owns its own passwd and I keep root passwd for myself (logged also Though I also use my pseudoroot...) so like that I check there is no one else but the allowed people doing the su to theyr accounts

All the best

Victor

[Tim Malnati]

A good habit to get into is to ALWAYS declare the user login id when changing a password. When you are su'd into a user account from root you can certainly change a password, but depending on the specific flavor of unix you may be changing the user's password and root's on others. Declaring the user login id eliminates any confusion forever (even if it's your own).

I can't answer your unknown id issue, I've never run into it with the arrangement I described (on both 10.20 and 11.0). My CDE menuing is setup to telnet or rlogin with the -l option so I login as the alternate root user. I also have some additional scripting going on so that my DISPLAY variable is automatically set after I'm in (another reason for a separate login).

[Bill Hassell]

Best advice you can get is to NEVER have multiple root users! Here are just a few of the reasons:

- Users tend to forget they are root and make very bad mistakes.

- The first thing a hacker does is to promote an ordinary user to root..it's just a 1-number change and hard to find by hand but has a very bad effect on your system.

- If you use SAM to remove one of the users when they leave the company, SAM will dutifully remove all files owned by that user--which happens to be every HP-UX system file on the computer.

The list goes on but the reasons all have very bad real world experiences. The rule is: NEVER use the root login if there is any other way to accomplish a given task. By requiring every SA to login as themselves, and then su to root only when required (securetty to prevent direct root logins). When a user logs in as themselves every day, after a while they completely forget that they are really root.

For new sysadmins, they should only be allowed to use sudo for selected commands to protect the production systems.

[Jerry L. Anderson]

We have our admins log in as themselves and use sudo to kick off a root window. Rather than knowing the root password, each admin user only needs to know their own password, and sudo is configured to prompt for it.

Our policy is that no one should log in directly as root - no way to tell who does what. Each time a user uses sudo to open an xterm as root there is an entry placed in syslog.log - thus we know who/when someone uses root.

Whenever a person leaves we simply disable their personal account and remove them from /etc/sudoers.

[Jim Hendrick]

Not sure why you get the failed login.

but PLEASE check out the sudo reference.

I've used it for years and would not have a UNIX system without it.

just introduce it gradually and learn the gotchas like;
sudo command > file # file gets your ID
and
sudo command1 | command2 # so does command unles you do
sudo command1 | sudo command2


Jim