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?

  • 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
  • 1
    7 years later, I'm wondering if you went ahead with it and what sort of BadStuff happened because of it... ^_^ – Mio Rin Sep 25 '18 at 16:39

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.

EDIT Another thought -- if you haven't already (which you should have), make sure that /etc/aliases contains an entry for root and a username that exists or an email address that evaluates correctly. A lot of automated systemwide tasks (cron for instance) send their output by email to root, which is traditionally aliased to the systems administrator(s) responsible for that system's operations.

| improve this answer | |
  • 2
    /etc/group also has the usernames ... – vrdhn 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
  • 3
    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
  • 2
    @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
  • 1
    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

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?

| improve this answer | |
  • 11
    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
  • 3
    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
  • 3
    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
  • 1
    Where in PCI does it say you need to rename ROOT? – Kidburla Feb 15 '18 at 20:55
  • @MichaelMrozek, Normally I would agree an answer should not have backstory like this. However, an internet search for this topic is laden with so many of the exact warnings OP spends three paragraphs talking about, I think it is called for in this case. It helped frame his "How To" paragraph and made it easier for me to follow knowing the context of his solution is similar to my own. – user1717828 Dec 17 '18 at 17:53

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 don't try.

| 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
  • On account of recompiling ... gogo gentoo? One patch into every Ebuild to rule them all? – Bananguin Feb 7 '19 at 10:08

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
razvan@naboo ~ $ su -
su: Authentication failure
razvan@naboo ~ $ su root2
naboo razvan # whoami

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

| 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 '14 at 11:01

Linux is not Windows and root can not currently be renamed easily without creating unknown future problems.

Disabling remote and even local login as root is a safer approach because it actively disables the account root! UBUNTU essentially does this and forces sudo instead of root access.

Essentially no one can use the root account to attack your system since it no longer can be used to login to the system!

It would be nice if a standard way was created to easily modify both the root account name as well as randomly generating its UID upon installation and if ever possible upon every cold start to prevent UID targeting but that currently does not exist.

Adjusting /etc/passwd Modify root:x:0:0:root:/root:/bin/nologin

Create a single fallback admin account for EMERGENCY USE ONLY! fallbackadmin:x:0:0:root:/root:/bin/bash

Implement sudo for all admins so that change log auditing can be implemented to accurately track who makes changes for accountability!

This implements the PCI US Gov requirements to disable default admin/guest accounts and create a single emergency use admin account.

One way to archive logs for auditing is to collect terminal history from all users with sudo account access if centralized AAA is not implemented.

A solution to implement admin only accounts is to create one user only account and one sudo enabled account then force the user to su to their sudo enabled account for administrative access.

You could also implement smart card authentication if you want better security there are solutions available for GNU/Linux that do compare to US Common Access Card CAC Solutions for two factor authentication.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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