Duplicating Root Account

[Khurram_4]

Hi All,
is there any way to duplicate root account in HP-UX11i B.11.11.
Regards
Khurram Mahmood

[Stefan Schulz · Accepted solution]

Hi,

just set up another account with the userid 0. Whenever this new user logs in he will have full root access.

Hope this helps

Regards Stefan

[Hai Nguyen_1]

Khurram,

You can assign userid of 0 to a user other than root This will make the user as powerful as root. However, I believe you should not do so.

Instead, you should try sudo software which allows a normal user to become root.

Hai

[James R. Ferguson]

HI:

Yes, but don't. If you must, simply add an account (via SAM or with 'useradd' [see the man pages]). Having added the account, edit '/etc/passwd' changing the uid of the new account to zero (0).

I said "don't" do this for the reason that you or someone else may later decide to delete the account you defined or to find and remove all files owned by it. Remember that the use of an account name is then mapped to its 'uid' -- which in this case is zero; which means that files owned by root are removed!

There are better ways to delegate subsets of root privileges. 'sudo' is one way. Setting up "restricted SAM" is another.

Regards!

...JRF...

[Pete Randall]

Be aware that this practice is dangerous. There is no way to distinguish between the two accounts since the uid number is the same. You will not be able to tell who did something. A mis-typed "rm" command from the wrong place can mean disaster.


Pete

[T G Manikandan]

this is not recommended

This is possible by creating a another user with UID 0 in the /etc/passwd file.

What is the need for the duplication of root user account?

You can either use SUDO or restricted sam (sam -r) to achieve things which require superuser rights.

[Jannik]

say you /etc/passwd is like this
root:/atpS.p7QRpnc:0:3::/:/sbin/sh
daemon:*:1:5::/:/sbin/sh
bin:*:2:2::/usr/bin:/sbin/sh
sys:*:3:3::/:
adm:*:4:4::/var/adm:/sbin/sh
uucp:*:5:3::/var/spool/uucppublic:/usr/lbin/uucp/uucico
lp:*:9:7::/var/spool/lp:/sbin/sh
nuucp:*:11:11::/var/spool/uucppublic:/usr/lbin/uucp/uucico
hpdb:*:27:1:ALLBASE:/:/sbin/sh
nobody:*:-2:-2::/:
www:*:30:1::/:
webadmin:*:40:1::/usr/obam/server/nologindir:/usr/bin/false

then add the line
crack::0:3::/:/usr/bin/ksh

do
passwd crack

then you have a user called crack with the same rights as root.

[Stefan Schulz]

Hi again,

i was to fast with my answer. I forgot to mention that this is not a good practice as the others stated.

Better use root when root privileges are required. If some other users need access to some functions requiring root privileges you might set up sudo.

Then you will knwo which user has access to which function. Also you might have a look at RestrictedSAM which you can set up as root inteactively in SAM.

So my answer should read: yes it's possible but not reconmendet.

Regards Stefan

[Bill Douglass]

Just to add one other not of caution, when you have two root-level accounts you increase your security risk. There are two possible avenues for hacking root access on the box now.

As mentioned, sudo is a very good tool, in that you can define what commands different users have. It also has very good logging, so you can monitor who did what. It is also a good learning tool, as many regular maintanance commands are logged in the sudo.log for other admins to study.

[Shannon Petry]

I wanted to add that some of you are not correct when you state that there is NO difference between the new user and root. This is absolutely false.

I will also add that certain applications completely fail for uncleare reasons if they run on the mimic'd root account.

The biggest reason why is that there are more than 2 ways to get your identity on the system, and one of these will produce different results. If comparisons are made while the application is running with different methods of lookup, then you have failure.

I.E.
getuid
geteuid

getusernam
getuseruid


If I run an app, and check who you are I may cache this. Lets say for simplicity sake I use getuid, check this against geteuid to make sure your who you say you are.
Lets say that I use the system environment variable LOGNAME from CDE to run my tests.

I have instantly failed =^O

This is another reason why NOT to run a mimic'd root account.

Regards,
Shannon

[Caesar_3]

Hello!

Yes edit the /etc/passwd
duplicate the line of root and change the
username, save the file.
Change the password for the new user
and now you have another user with same
uid like root.

Caesar

[Martin Johnson]

With a majority against using a pseudo root account, I will point out some good points for using a pseudo root account.

First, if you have problems with your root password, you can use the pseudo root account to change the root password without having to go into single user mode. This can be very important on a production system where downtime is frowned upon.

Two, contrary to what some say, you can get accountability from a pseudo root account. Auditing and utilities like "last" will give you information on a pseduo root account. In fact, our auditors insist on pseudo root account over several people having access to root for increased accountability.

HTH
Marty

[Shannon Petry]

Martin, going to pick you apart for a second.

"First, if you have problems with your root password, you can use the pseudo root account to change the root password without having to go into single user mode. This can be very important on a production system where downtime is frowned upon."

If a system has a corrupt passwd file, 99% of the time this will require single user mode to fix even with a mimic'd account.

Exception of course is lazy admins who change passwords and dont document the changes, or so so with no caution (I.E. caps lock,num lock, etc...).
In more than 15 years working with Unix of all flavors, corrupt passwd files are empty and 0 byte size 99% of the time. A mimic root account is denied access just like root and any other user when this occurs.

"Two, contrary to what some say, you can get accountability from a pseudo root account. Auditing and utilities like "last" will give you information on a pseduo root account. In fact, our auditors insist on pseudo root account over several people having access to root for increased accountability. "

False!
The only accountability is showing the last time that the mimic account is logged in. 99% of the applications run use getuid() to determine who is running it for logging purposes, meaning that root is logged for most actions/transactions.

Any accountability as to when a mimic account did anything other than log-in is guess work, non-factual. In cases where a cron job is run, at jobs are run, or backgrounded jobs are run there is no possible way of showing who ran what.

Are there environments where you can get away with this? Sure there are.

Would I ever recommend to a customer that they use this as a method when "sudo" is available? NO!

Using sudo you can completely log actions and control access to the system's root command sets.

Of course it does not fix when Admins screw up the root password. That being said if this is such a common problem, you may want to find a new Admin.

Regards,
Shannon

[Martin Johnson]

Shannon,

In the dozen or so times I've been locked out of the root account over the last 10 years, it was due to someone locking out the account by entering the wrong password. Quickly remedid with a pseudo root account.

The one time I did have a corrupted password account, I was already logged in under my pseudo root and quickly fixed the problem.

It is our policy that pseudo root accounts are not authorized to use cron, batch etc. And you are correct, there is not full accountability, but that is different from no accountability.

I agree that sudo is the correct way to go, but try supporting NNM,OVO,MWA under sudo (or RBAC under solaris). You will find keeping up with all the utilities used is a maintenance headache, especially when Murphy requires their use at 2:00 AM.

Besides, I was just be devil's adovacte. :-)

Marty

[Shannon Petry]

I understand ;) I was just playing back!

We all have reasons for doing what we do, and most dont match someone elses situation and could not be made to do so.

Hence the beauty of Unix. There are an infinite number of problems and an infinite number of solutionis. Unlike M$ where if its not in a gui it cant be done.

Sincerely,
Shannon

[Siddhartha M]

The following thread also discusses duplication of root accounts:

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x2c5b0ea029a2d711abdc0090277a778c,00.html

You may find some more pointers to your question here.

[yogesh_4]

Hi,
To create user account with root access is simple , just set UID to 0 for any usr will get root permitions. but I will suggest not to use this , instead you can download "SUDO" software whai is available free on http://hpux.cs.utah.edu.

Thanks

[John Collier]

Khurram,

At lease they were somewhat more civilized with you when you asked. They pretty well hammered me when I started my thread:

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x4bdae822e739d711abdc0090277a778c,00.html

I give you this link for your continued education on this matter. I can tell the tread is closed and I would hope that you would assign me a 0 (zero) for this post when you get around to assigning the rest of the points for all of your valid answers.


{At least you didn't post to the end of your own old thread. Watch the vultures attack on this one! ;-) }

[Ronelle van Niekerk]

It is not safe practise but sometimes you just have to do it.
I had to do this once, the dba's needed only certain commands and sudo was not an option.

So what I did was to create the user with uid = 0 and then I created a menu system for them. The menu contained only those commands they needed and allowed for variables to be entered.

I made sure they could not exit the menu and that the menu started up for all intances of their logging in with that user.