0

I'm since a few years a Linux Admin and I know that I can change the password of root when I reboot the system with a live system and mount the / or /etc (depends on the directory distribution). I have now a bigger problem.

I think there went something wrong when I used VI and the first line of /etc/passwd have changed the first letter in to a capital letter. So now there is Root instead of root. Is there any way to change this as an normal User?

It is running on an Cisco Server and I could even acces the system trough iLO and the KVM Switch. So there would be ways to get on the system. But it is a 24/7 System so I can't shutdown the Server.

I would appriciate any kind of help you can give me. Thank you.

Phillip St.
  • 11
  • 1
  • 3

3 Answers3

1

UID 0 not being called "root" does not mean you are locked out. Here's a system after I manually edited /etc/passwd and /etc/shadow and logged back in as the new name for root:

SuperUser@sf:~# id
uid=0(SuperUser) gid=0(Root) groups=0(Root)

Use the spelling that is in /etc/shadow which has the actual hashed passwords. However, only root can read this file. Possibly you want "root" if you only changed passwd to "Root".

You cannot edit passwd as a regular user, that breaks its security. A user could impersonate anyone they want, including becoming uid 0.

You don't need a text editor to change users in local files. See the man page of usermod and related commands from shadow-utils.

The OS administrator should have some way of becoming root from their usual personal user. Such as sudo rules or known password. If you are to change the login of root, you are an OS admin.

You always need a maintenance window for system downtime. Security patches, if nothing else. So if you still can't get in, get one on the calendar to fix this, even if it is a few months from now.

John Mahowald
  • 30,009
  • 1
  • 17
  • 32
0

Do you not have a sudoer on the system that you have access to? If not, you need to find an exploit on the system. Perhaps something that root's cron executes that is writable by your user. Check /var/spool/cron/root to see if anything applies.

Next is to look for any services that have exploits. A program running as root that would allow you to execute an arbitrary command or that automatically executes a writable script/program.

Next, look for programs with setuid() and the applicable sticky bit set and see if there's something you can exploit there.

If it's a system that's built "out of the box", then you're likely screwed and will need to shut down the PC, mount the drive as a slave in another Linux host, and modify the file from there.

Good luck!

UtahJarhead
  • 908
  • 7
  • 14
0

I hope never been in your situation, it is really bad! I think do not have a lot of solution if there have no sudoers configured and reboot cannot be performed.

Sorry man, it is a long time I'm seat here to think how can fix this problem, but I'm afraid that nothing can be done without user can elevate to uid 0 from that system (sudo) or by running a live system to access physically the data with uid 0.

AtomiX84
  • 415
  • 2
  • 7