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.

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?

share|improve this question
    
Is this a hypothetical situation that you are proposing? –  Chris Down Sep 18 '11 at 21:53
    
I had indeed done exactly this on a (relatively fresh) FreeBSD install. It has since been reinstalled, so I suppose it is now somewhat hypothetical, but I'm curious about what the best route to recovery would have been if I indeed did have full system present. –  noffle Sep 18 '11 at 21:59
    
Been there, done that, got the t-shirt. But as a result on every machine I administer I maintain a backup root account, just in case. –  Mark D Sep 20 '11 at 20:37
add comment

5 Answers

up vote 28 down vote accepted

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?)

share|improve this answer
    
Nice for the exec, but I guess it's better not to mess up too much with mount points beforehand. –  Stéphane Gimenez Sep 18 '11 at 23:12
2  
@Stéph You have to do that if your kernel does not mount root read-write. Otherwise you won't be able to modify any files (including /etc/passwd). –  rozcietrzewiacz Sep 18 '11 at 23:18
    
Good thinking! I had managed to get into single-user mode, but it didn't hit me that I had to remount / as read/write to modify /etc/passwd. Thanks! –  noffle Sep 19 '11 at 2:16
    
@roz Sure, I was trying to say that I would take care of unmounting everything else might have been mounted (other than /) before executing init. –  Stéphane Gimenez Sep 19 '11 at 10:41
2  
+1 for anthropomorphizing the kernel. –  Tyler Holien Sep 23 '11 at 17:22
show 1 more comment

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.

share|improve this answer
1  
Good ideas. =) As you suspected, no other users can use 'su'. sshd also has root login disabled. –  noffle Sep 18 '11 at 21:48
add comment

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.

share|improve this answer
    
Wow, I just noticed you posted the same answer in the same minute as myself :-) –  rozcietrzewiacz Sep 28 '11 at 8:30
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
    
You should point out the risks connected with manually editing the /etc/passwd file. Other than this, good point - I just wanted to add the same suggestion to my answer. –  rozcietrzewiacz Sep 28 '11 at 8:35
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.