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:
>>>
>>> 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.
|
