On Wed, Feb 1, 2012 at 6:05 PM, Nico Kadel-Garcia <[log in to unmask]> wrote:
> On Wed, Feb 1, 2012 at 5:36 PM, Yasha Karant <[log in to unmask]> 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.