On Sat, Feb 4, 2012 at 2:22 AM, Yasha Karant <[email protected]> wrote: > 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?
Yes. And in the same bug, someone else reports: "I ran into this today with F14. I always remove 'rhgb quiet' from grub, and I tried rebooting adding 's' to get to single user mode. I was shocked to find that I was still getting the password prompt in single-user mode!" So having a corrupt filesystem, "SINGLE=/sbin/sulogin" in "/etc/sysconfig/init", and "rd_NO_PLYMOUTH" (and no "quiet" or "rhgb") on the grub kernel line, _MIGHT_ allow password-less access to a system (if this is your case, you should report it to RH as a bug!).
