On 02/03/2012 02:43 PM, Tom H wrote:
> On Wed, Feb 1, 2012 at 9:04 PM, jdow<[log in to unmask]>  wrote:
>> 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.
>
> I've just re-read the whole thread. You're right; it started out about
> a bug entering the root password in single-user mode after filesystem
> corruption.
>
> A solution was pointed to
>
> http://listserv.fnal.gov/scripts/wa.exe?A2=ind1202&L=scientific-linux-users&T=0&P=243
>
> but Yasha somehow decided that it would turn off the password prompt
> for single-user mode when all it does is turn off plymouth and allow
> someone in his situation (according to the Fedora bug) to enter the
> root password.

Please excuse my obvious misunderstanding, but the URL that was 
mentioned and that you repeat contains the statement:

With rd_NO_PLYMOUTH I don't get a prompt for the password for the root
filesystem encryption, but that's a minor matter relative to the problem
itself.

End quote.

Not having a prompt for the password is what is stated.  Thus, I assumed 
that under a call to fsck during boot with an abnormal exit from fsck, 
the default behavior of rd_NO_PLYMOUTH would be to allow root access 
without a password during boot.  Admittedly, a boot root password under 
these circumstances is little protection to a determined attacker who 
has physical access -- but it will deter the casual hacker.  By analogy, 
it is rather like a deadbolt lock on a wood frame and wood door without 
metal armor, a reinforced wall and door frame:  a determined attacker 
simply kicks in the door, but a casual thief finding the door locked and 
unwilling to break a window leaves.

I have not done the experiment as if it fails, I do not want to have to 
go through the rescue DVD approach again unless I must.  Has anyone done 
the experiment with SL 6x and verified that rd_NO_PLYMOUTH allows for a 
successful request of a legitimate root password?

Yasha Karant