On 02/03/2012 02:43 PM, Tom H wrote:
On Wed, Feb 1, 2012 at 9:04 PM, jdow<[email protected]> wrote:
On 2012/02/01 15:38, Tom H wrote:
On Wed, Feb 1, 2012 at 6:05 PM, Nico Kadel-Garcia<[email protected]>
wrote:
On Wed, Feb 1, 2012 at 5:36 PM, Yasha Karant<[email protected]> 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
