If I want to Set a root password, and protect it so it CANNOT be changed, is there a way to do it?

The reason I ask, is that Me and a partner are starting a new venture, and we picked up another partner, that he knows, but I do not.

I don't trust him, because I do not know him. My partner does trust him though, but I just want to make sure he cannot lock me out of the servers we are going to be running, which I'll have to give him root access so that he can take care of stuff when He is the only one "in the office"(on the clock).

Could I run this command to stop the password file from being able to be "overwritten", so that the server cannot update the password, unless I undo it just to change the password:

chattr +i /path/to/passwd

Plus, do you know of a other way to log all the activity root does in shell/telnet? Other then writes to the ONE location the .bash history?

Thank you!!!!
Richard

I think there is not way to do that because he have complete control over the server by being root and be root means you have control over everything, but I may be wrong this is just my opinion.

He can't lock you out of the server. Well, he can of course, if he has root, but you will have a good backup and in the worst case scenario you just restore the whole server from backups.

If just the root password has changed, and the server is otherwise OK, you boot from a floppy or CD and change the root password yourself.

Iain.

Yea, set to a different password and lock his but out. again. Of course he can do the same to you though.

Howzit

U could be really nasty and change the passwd file to another name if u want to view what files have been change then why not try setup tripwire. As root he can pretty much do what he likes..........

chow

Hmm, so as root, he will of course be able to do everything. Is there a way I can give him superuser powers, except not with the username root, where he cannot change the root password, but be able to do everything else I might need him to do?

That's possible but tricky.

You can use sudo to give him access to specific commands, but you would have to list them all. I don't think there's an easy way to say "user x can do everything except change root's password".

You might also be able to use roles/groups to achieve something similar (depending on your distro) but again, excluding just one function is difficult.

Howzit

There r ways that u can even block root from doing alot of things on a linux box take a look at this version of linux for example www.nsa.gov/selinux. This version of linux has Mandatory Access Controls which allows u to specify what u allow even root to do on the system.

Try using an app called LIDS this is MAC for Linux

chow

the question is, should (or do) you really be giving direct access to root to this guy in the first place ? learn how to deploy sudoers effectivly

Howzit

Found this link which explains MAC and it also mentions open source software as well as comercial software that u can buy.

http://www.unixreview.com/documents/...106m/0106m.htm

chow

Plus, do you know of a other way to log all the activity root does in shell/telnet? Other then writes to the ONE location the .bash history?
Please have a look at your other thread: http://www.linuxquestions.org/questi...hreadid=104533
Next time try to keep your questions in one place. It shows you know netiquette and saves us time and effort. Btw, IMHO logging *everything* root does isn't feasable unless you have separate syslog server with Terabyte storage.

Is there a way I can give him superuser powers, except not with the username root, where he cannot change the root password, but be able to do everything else I might need him to do?
"Sudo" is your tool of choice as the rest said, and I agree with that (some risks there too tho). ACL's are some way to curb risks, but they're not the whole solution. Btw, Grsecurity also works with ACL's and per-process capability restrictions.


The "better" answer would of course be to be honest about the trust problem and come up with a solution together. Unless you define trust very clearly (Iainr's roles/groups suggestion) it will remain nothing more than a gut feeling, and I wouldn't want to be dealing with admin policies based on something as opaque that...