On Wed, 1 Feb 2012, 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: =A0the bug in accepting the root password upon=
> a
>>> failed fsck during boot is from TUV and documented (please see a previou=
> s
>>> post nominally in this thread). =A0Is there any fix? =A0I do not care if=
> the fix
>>> "breaks" TUV bug-for-bug compatibility -- is there a fix to which routin=
> e(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 =A0separate 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".

There is even a "rpm" for that called SL_password_for_singleuser .

>
> As Nico's shown, you can also set a grub password to prevent anyone
> from adding "init=3D/bin/sh"/"init=3D/bin/bash" to the "kernel" line
> without that password.
>

-Connie Sieh