On Wed, Feb 1, 2012 at 6:05 PM, Nico Kadel-Garcia <[email protected]> wrote: > On Wed, Feb 1, 2012 at 5:36 PM, Yasha Karant <[email protected]> wrote: > >> Back to my primary point: the bug in accepting the root password upon a >> failed fsck during boot is from TUV and documented (please see a previous >> post nominally in this thread). Is there any fix? I do not care if the fix >> "breaks" TUV bug-for-bug compatibility -- is there a fix to which routine(s) >> are causing the problem? > > This is, in fact, an option to configure in grub in the older LILO > boot loader. Run the command "info grub-md5-crypt" for more > information. > > This is not normally considered a "bug". The software is not doing > anything that is not expected or undocumented. It's a *risk*, and some > folks might think it's a security flaw. But the burden of storing and > managing separate password for deployed systems is not, hirsorically, > taken up by default. It would have to be written into the OS instaler > to apply on the existing boot loader software. So it's not set by > default.
It's not a bug; it's a TUV decision. Requiring the root password for single user mode can be set through "/etc/sysconfig/init". As Nico's shown, you can also set a grub password to prevent anyone from adding "init=/bin/sh"/"init=/bin/bash" to the "kernel" line without that password.
