Description of problem: We had a system with a failing disk today and it simply dropped into a root shell with a "(repair filesystem) #" prompt and gave a message to run fsck manually. Version-Release number of selected component (if applicable): Fedora 15 util-linux-2.19.1-1.4.fc15.x86_64 kernel-2.6.40.6-0.fc15.x86_64 How reproducible: I presume it happens whenever a filesystem inconsistency is detected at boot. Steps to Reproduce: 1. Find a failing disk or corrupt filesystem 2. reboot Actual results: A root shell is given at the console. Looks like initrd is root disk. A user can then mount the hard disks and do as they like, e.g. change/steal root password. Expected results: Should require root password. This was the case in Fedora 14 and before as well as other *NIX OS's. Additional info: If root password can't be read from disk, then the administrator should have to boot from another media. We have a number of Fedora machines in a lab setting. In order to keep them secure we lock the cases and disable booting from anything but the first hard disk in a password protected BIOS. With things the way they are, a user can hijack a machine if it is rebooted and needs an fsck.
I think sulogin(8) should be started in this case, reassigning to our initd.
(In reply to comment #0) > We had a system with a failing disk today and it simply dropped into a root > shell with a "(repair filesystem) #" prompt and gave a message to run fsck > manually. This looks like dracut's emergency shell prompt from fs-lib.sh. > A root shell is given at the console. Looks like initrd is root disk. Another indication for me to reassign to dracut.
if you want to secure your machine: 1. set a grub password, to prevent "init=/bin/sh" or "rdinit=/bin/sh" 2. add "rd.shell=0" to the kernel command line, to prevent a shell in dracut
btw, there is no /etc/shadow in the initramfs to check a root passwd against.
We allow the users to configure the 'normal' single/etc prompts to prompt for a password. It would be a nice RFE if we could make dracut honor the same configuration. As stated in comment #4, shadow (and auth in general) is an issue.
Thanks for the info in comment 3, we'll implement this as a workaround. I do feel strongly, however, that something needs to be changed here. Dropping the user into a root shell whenever something goes wrong with the system introduces a huge security problem, even if it is only for those with console access. If one finds a way to trigger an fsck on a default system they get instant root.
Mine did the same thing dropped to sh shell without requiring password! I'm using Fedora 16 verne but before it was Beta. My problem began when I just had updated my software updates and it updated Linux kernel from fedora (3.1.5-1.fc16.i686) to 3.1.5-2.fc16.i686 rpm 32bit, then my laptop started acting unstable with a sign Oh no! Something has gone wrong. A problem has occurred and the system can't recover. Please log out and try again. So I did that and then it read Need to contact adminstrator, of which I am. After booting back up everytime it displays....even if I try booting the others, it still does same. Booting 'Fedora (3.1.5-2.fc16.i686)' Loading Fedora (3.1.5-2fc16.i686)' Loading initial ramdisk... _Fedora-16-Beta-: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. (i.e., without -a or -p options) dracut Warning: e2fsck returned with 4 dracut Warning:_Fedora-16-Beta-contains a file system with errors, check forced. dracut Warning:_Fedora-16-Beta-: Inodes that were part of a corrupted orphan linked list found. dracut Warning: *** An error occured during the file system check. dracut Warning: *** Dropping you to a shell; the system will try dracut Warning: *** to mount the filesystem(s), when you leave the shell. dracut Warning: Dropping to debug shell. sh: can't access tty; job control turned off (Repair filesystem):/# HELP would be most appreciated because I haven't the slightest clue how to fix this nor what went wrong. I tryed typing in fsck and it then reads fsck from util-linux 2.20.1
(In reply to comment #7) > HELP would be most appreciated because I haven't the slightest clue how to fix > this nor what went wrong. I tryed typing in fsck and it then reads fsck from > util-linux 2.20.1 Try: fsck /dev/disk/by-label/_Fedora-16-Beta-
Yes, I view your post as another way of locating my problem to correct it, and you all are most helpful. But beforehand, I have ask this same question at( http://ask.fedoraproject.org/question/682/shell-command-to-fix-filesystem ),and before I checked back here, the bug that ceased my laptop inoperable was solved with this answer from there::: type "blkid" (without quotes) to find out which partition is called Fedora-16-Beta It will probably be something like /dev/sda2 or possibly /dev/mapper/xxxxx Once you know which one is Fedora-16-Beta, type the command: fsck -y /dev/sda2 (substituting whichever partition was called Fedora-16-Beta) then type exit and hopefully you will be fixed up::: The Fedora-16-Beta whereas all errors and corrupt files got corrected and fixed was in my harddrive /dev/mapper/boot or root, I forgot. Anyways it was a simple fix. Thanks to the new package dracut for catching it, you Michal at RedHat and ask.fedoraproject.org for the excellent help and for having grown to be the world's best of Operating Systems!!!!!
I contest that this was closed as "NOTABUG" Please disregard comment 7, 8 and 9 and read the content of this bug. The system drops into a root shell by default when an fsck is needed. In my mind, this is a serious security hole. I would argue that at least "rd.shell=0" should be added as a default kernel parameter until something better can be done. Otherwise, an unprepared systems administrator has no idea that a user will suddenly get a root shell one day. That's exactly what happened to me.
(In reply to comment #10) > I contest that this was closed as "NOTABUG" Please disregard comment 7, 8 and > 9 and read the content of this bug. > > The system drops into a root shell by default when an fsck is needed. In my > mind, this is a serious security hole. I would argue that at least > "rd.shell=0" should be added as a default kernel parameter until something > better can be done. Otherwise, an unprepared systems administrator has no idea > that a user will suddenly get a root shell one day. That's exactly what > happened to me. This just has to be documented more prominently: If you want to secure your machine: 1. set a grub password, to prevent "init=/bin/sh" or "rdinit=/bin/sh" 2. add "rd.shell=0" to the kernel command line, to prevent a root shell in dracut in case of boot failures.
Don't you think Fedora should be a secure OS by default?
(In reply to comment #12) > Don't you think Fedora should be a secure OS by default? It is not, unless you set a grub password ( and add "rd.shell=0" )
Does grub give the option to set a password during install? I thought it did but can't seem to recall. I suppose I would feel better if there was at least a check box in anaconda. In any case, just saying "it's not secure" doesn't mean it shouldn't be.
reassigning to anaconda, to set "rd.shell=0" if a grub password is installed
Patch posted.
Fix pushed to rawhide.
Thank you!