Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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?

share|improve this question
    
the account name "root"? the toplevel directory "/" ? –  akira Mar 2 '11 at 5:59
4  
the username root –  yxkb Mar 2 '11 at 6:00
1  
then please clarify your question ... –  akira Mar 2 '11 at 8:55
add comment

4 Answers

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.

share|improve this answer
    
Admittedly as @5mi11er pointed out I haven't tried this but if root's shell is set to /bin/false or /sbin/nologin it would be unable to start any services. So all of those would have to be reconfigured. Plus the whole purpose was to improve security, adding a second account with "root" permissions hardly improves security. –  Bram May 29 '12 at 7:42
    
I think this solution is the best so far, it allows name to uid lookup for root and disables login for root. You could swap the order of the lines so root2 appears before root, then whoami will report root2, ie. uid to name lookup stops when the first uid entry is matched. I don't agree that services will not be able to start, since the kernel starts a process and gives it uid 0 to setup the system (init, upstart, ...) –  X Tian Jan 9 at 11:01
add comment

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.

share|improve this answer
1  
/etc/group also has the usernames ... –  Vardhan Mar 2 '11 at 10:08
    
Only of usernames when the group in question isn't their default group, but good point. –  Shadur Mar 2 '11 at 10:33
1  
is it? i thought most of the apps go for UID and not the name.i think ideally, no application should assume "root= UID 0" –  yxkb Mar 2 '11 at 17:10
1  
@yxkb: You're right no application should assume that. But I'd really like to recieve 1$ for every application or script that does! :) –  Bram May 29 '12 at 7:27
    
Indeed. Let's think of all the times we've all personally written chown root … or similar in a shell script. –  derobert Jan 7 '13 at 16:34
add comment

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?

share|improve this answer
1  
This would be a rather better answer if you cut out the several paragraphs dedicated to calling people ignorant; it's not really necessary –  Michael Mrozek Mar 30 '12 at 16:49
    
You're right, but it took a while for me to admit it. It's intent was to help ensure that others had actual experience with changing the root username before just bashing the idea, but it really wasn't needed. –  5mi11er Apr 3 '12 at 14:24
    
Since you are on CentOS: can you check what rpm -Va says on systems where the root account is renamed? According to Maximum RPM guide "The user and group identifiers must be non-numeric" so any RPM that specifies files must be owned by root would be unable to do that at install time. Just wondering how your systems would deal with that. –  Bram May 29 '12 at 7:35
add comment

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.

share|improve this answer
2  
I don't think anyone is disputing that renaming root is, at best, a terribly bad idea. –  Shadur Mar 2 '11 at 11:59
    
kuhkatz, its just a precaution. if someone does that, it might help to revert it if you know what happens when someone changes root –  yxkb Mar 2 '11 at 16:59
    
the article you got that idea from notes that doing it breaks login as root, as using sudo. therefore, you only way to revert it would be a clean reinstall. therefore, you dont have to try it, it is obviously how to restore it. also, have a LART on hand, just in case a user of yours tries anyway. –  kuhkatz Mar 3 '11 at 8:26
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.