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: >>>
>>> 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. This is Yasha's original issue, *separate* from password protection for the boot loader. Yasha brought up what he considered a separate "bug", that the init=/bin/sh stunt works by default, and that is what I've been saying "that's not a bug, it's a documented part of how things work, please don't derive software behavior from first principles and then say 'that's a bug' when it doesn't work the way you thing". It's tempting, and I've done it myself, but it leads to confusion. The broken root password handling is a distinct problem. It's clearly a failure, but is probably not a boot loader bug. The system had a corrupted filesystem due to an unmanaged shutdown during a power failure. The state of such a system is unpredictable, and it's.... unfair to blame the bug on the boot loader when the filesystem may be hosed and demonstrably needs to be fsck'ed. No one can fix that for you from the installed software side, because the state of the data on the disks is unreliable and cannot be trusted to be reliable software. It has to be fixed That's what rescue and recovery media are *for*. I'd be curious if Yasha can *now* reboot into fsck requiring mode. Yasha? Do you feel like testing that? You could use 'tune2fs' to lower the max-mount-counts to, say, 3, and reboot a couple of times to get it do demand an fsck.
