On Wed, Feb 1, 2012 at 6:44 PM, Yasha Karant <[log in to unmask]> wrote:
> On 02/01/2012 03:05 PM, Nico Kadel-Garcia 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.
>
>
> 18 Invoking grub-md5-crypt
> **************************
>
> The program `grub-md5-crypt' encrypts a password in MD5 format.  This
> is just a frontend of the grub shell (*note Invoking the grub shell::).
> Passwords encrypted by this program can be used with the command
> `password' (*note password::).
>
>   `grub-md5-crypt' accepts the following options:
>
> `--help'
>     Print a summary of the command-line options and exit.
>
> `--version'
>     Print the version information and exit.
>
> `--grub-shell=FILE'
>     Use FILE as the grub shell.
>
> I am confused.  In the past, both with LILO and GRUB without any special
> invocation, whenever fsck failed on boot or reboot, the password prompt
> would appear and the root password used during normal operation of the
> system would be accepted, allowing me to run fsck manually (actually, to
> manually invoke a script I write that invokes fsck).  I had to do no special
> configuration to grub during normal operation and prior to being allowed to
> enter the root password.
>
> Now, with just one character (keystroke), as explained in the bug report
> previously posted to this thread, the password acceptance routine attempts
> to process the "password", fails, and loops to the same enter password
> prompt.
>
> Are you stating that by invoking grub-md5-crypt during normal operation, and
> providing grub-md5-crypt with the plain text root password, said password
> will now be accepted rather than stopping at a single keystroke?
>
> The only reference I could find indicated that I must modify grub.conf to
> include the stanza:
>
> password --md5 <encrypted password>
>
> where <encrypted password> is the actual set of characters displayed for the
> root password in the /etc/shadow file.
>
> Does one use grub-md5-crypt, or this latter password stanza?  When did this
> change?  In EL 5, using grub, this special stanza was not required to the
> best of my observation.

Backup. The grub-md5-crypt command, like the htpasswd command, has
*nothing* to do with /etc/shadow or /etc/password. It's useful to
generate an encrypted password for *grub*, which is usually stored in
/etc/grub/grub.conf. It happens to be an MD5 password, so the
structure of the stored password is similar, but they can be entirely
distinct passwords.

Please, please, actually go read the docs on the software you're
criticizing or saying must have a bug.. Don't theorize from how you'd
expect someone to do it, because this seems to keep leading you into
confusion. In this case, grub cannot reasonably access /etc/shadow
because the filesystem drivers for the / partition aren't necessarily
loaded until *AFTER* grub or another boot loader runs, so getting the
password data from /etc/shadow is infeasible. That's why the encrypted
password is stored in /boot/grub/grub.conf, which *is* accessible to
the grub boot loader.

And be very glad we're not still using LILO. That was even harder to
read and configure.

> Yasha Karant