Recovering from setting root's shell to a bad file

Question

Let's say I've gone and done a silly thing, such as using 'chsh' to change the root user's shell to a bad file path. Future logins to the root account will abruptly fail, citing /bin/whatever not being found, and boot you back out to the login screen. Barring a recovery mode or inserting a LiveCD to edit /etc/passwd, what are my options for getting my system back? Let's also assume (for fun?) that there are no other users in wheel. Thoughts?

Answer 1

When booting, append init=/bin/bash (or a path to any other functional shell) to your boot options - you will be dropped straight to a single user shell. You might need to do mount -o remount,rw / before modifying the /etc/passwd entry in that environment. After that, just reboot or do exec /sbin/init 3. Just do not type exit or press Ctrl+D, as these would result in kernel panic*.

One additional variation of this method might be necessary on some systems loaded in two-stage mode (with an initrd image). If you notice that the boot options contain init= and, most importantly, real_init=, then the place to put /bin/bash should be the latter parameter (i.e. real_init=/bin/bash).

_{* This is because in that environment, the shell is seen by the kernel as the init program - which is the only process that kernel knows - it represents a running system underneath to the kernel's eye. Suddenly ending that process, without telling the kernel to shutdown the system, must result in kernel panic. (Wouldn't you panic if suddenly everything around you went black and silent?)}

Answer 2

You could use su and specify a shell to execute (I'm not sure if you're trying to imply this isn't possible with your note about no other users being in wheel):

su -c /bin/bash

Otherwise you could do something similar if your ssh daemon allows login to root:

ssh root@localhost /bin/bash

You could also set a shell as your init in your bootloader, for example, init=/bin/ksh or similar.

Answer 3

If your bootloader is configured to allow live editing of the kernel parameters, a solution is to reboot and use a shell as init process, e.g. init=/bin/bash. Then, mount whatever needs to be mounted by hand, and edit /etc/passwd. sync and boot again with your usual init.

Answer 4

If the gist of your question is that you've locked out all the ways to become root, then by definition you cannot become root.

It is common to allow three ways to become root on a unix system:

• Log in as root, by entering root at a login prompt and typing the root password. This runs root's shell.
• Log in as an ordinary user, then become root by running su and typing the root password. On some systems, this requires being in a particular group (often called wheel); on other systems, anyone who knows the root password can become root. Systems using PAM for authentication use pam_wheel to manage the wheel group if they have one. If you specify a command with su -c, it is executed via root's shell.
• Log in as an ordinary user, then become root by running sudo and typing your own password. The user account must have been given sudo powers by an administrator. Unless restricted in the sudoers file, you can run any command, regardless of root's shell.

A traditional way to protect against root's shell being unavailable is to define another account with UID 0 and a different shell (toor is a traditional name). For example, if root's shell is a dynamically linked executable (a good idea to conserve memory) and a library upgrade goes wrong, root's shell might be unusable. The alternate root account would have a statically linked executable, possibly one with common utilities built-in such as BusyBox.

Answer 5

The above answers are great and I learned from reading them. If you don't remember the details of these approaches and don't mind rebooting, you can always boot your system using a live CD distro, mount the / partition and then edit /etc/passwd and reboot. Not as elegant as the above solutions, but easier to remember.