On 2012/02/01 15:38, Tom H wrote:
> 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.

It is a bug, IIRC. The original complaint is that it claims it is ready
to accept the root password and something prevents it by causing the
login prompt to recycle with each character typed. That has been declared
a TUV bug. I think somebody mentioned there might be a fix for it that has
not percolated through yet. It'd be worth checking TUV's bugzilla.

{^_^}