How do you rename root?

Question

Not that it's a very good idea to change it, but for fun. According to this post, there are still some problems even after changing entries in /etc/passwd, /etc/shadow, and /etc/sudoers. Any suggestions?

Answer 1

Theoretically, changing it in /etc/passwd and /etc/shadow would be all you need to 'rename' root. The problem occurs because pretty much every single piece of Unix software in existence assumes that the username 'root' exists and that it is the superuser -- mail aliases, various daemons, cron...

If you're really hell bent on trying it, find /etc -type f -exec grep -l root {} + should be a good start at finding a list of every config file you'll probably need to change - but like you already said, this is a really bad idea in almost every conceivable situation.

Answer 2

All this fear mongering, saying "Don't do it!" is ridiculous. At one time, yeah, it probably did break lots of badly written scripts, but I suspect those are not so common any longer; at least not in the standard distributions.

We've been told to rename the root account on a subset of linux servers. So, after attempting to research how to go about doing this correctly, I, instead found many, many posts saying "Don't do it!" with lots of dire warnings of "bad stuff" happening if you choose to do this. But, I have yet to find any with concrete examples of the "bad stuff" that could happen.

So, let me back up and explain where I am, and how we got here. We're building a PCI compliant environment, and one of the tools that helps us meet those "requirements" is telling us we need to rename the root and administrator and guest accounts to something else. For those uneducated about PCI, you have the option of either following the guidelines or documenting why you either can't or choose not to follow that guideline, and what mitigating strategy you have to keep the systems safe. So, I imagine most places document why they aren't going to rename their root accounts, however, our group has decided that, if we can rename the windows administrator accounts without problem, were going to rename the linux root accounts as well.

I am well versed in the "security through obscurity" arguments; I know just changing the root account name doesn't actually improve security by a lot, root should be disabled at SSH, etc. I know, that's not the point, I'm not interested in hearing more. I'm also not interested in more "the sky will fall" warnings. I'm looking for statements like this: ">this bad thing< will happen with >this standard package< (unless you >do this<)".

So far I have 3 CentOS (RHEL) systems that apparently have no issues with renaming the root account. Here's what I did: I changed the account name in /etc/passwd, /etc/shadow, /etc/group, and /etc/gshadow. Then grepped for the name root in /etc/ and modified the postfix aliases file so that root was an alias to our new account name, call it rojotoro. (Something similar should be done for other email systems). I also found that I needed to change some configurations for logrotate when describing who should own the files it would create automatically. And that has been all I have changed thus far.

I've looked at many init.d scripts, but haven't changed anything, and everything appears to start just fine at boot. I have to specify the new account when using sudo: "sudo -u rojotoro vim /etc/passwd" as an example, but I didn't actually need to change anything within the sudoers file. I expected maybe some issues with selinux which we have on and enforcing, but thus far I've not needed to touch that system.

I can also see that mkdev or mkfs scripts may need to be adjusted, but I don't plan on using those, so I haven't looked at them with the scrutiny they deserve.

If it truly is this easy to change with no ill effects on an selinux enabled system, why the continuation of all the fear mongering?

Answer 3

suggestion: do not do that.

some tools try to talk to root via uid, there you should not have problems. some tools assume your root account is called root, and will break. unless you are prepared to, like, recompile half your system "for fun", just dont try.

Answer 4

To my mind, the easiest thing to do is to create a new user (alias), with UID 0 and /root as home.

Why don't you switch your root's default shell to /bin/false or /sbin/nologin (so no one can login to it, but the system still use it) and login to the new alias created?

razvan@naboo ~ $ head -2 /etc/passwd
root:x:0:0:root:/root:/bin/nologin
root2:x:0:0:root:/root:/bin/bash
razvan@naboo ~ $ su -
Password:
su: Authentication failure
razvan@naboo ~ $ su root2
Password:
naboo razvan # whoami
root

If you change root's shell to nologin, the sudo, mail or ftw will not be damaged.