Red Hat Bugzilla – Bug 181740
passwords specified in kickstart file are discarded by interactive mode
Last modified: 2007-11-30 17:11:24 EST
Description of problem:
Even though my kickstart files specify passwords for both grub and user root, if
I start the kickstart install in interactive mode, such passwords are silently
discarded. This is not so much of a problem for the root password, since it
won't let you get past that screen with a blank password (maybe it could use the
ks file password if I tried?), but as for the grub password, not even the option
that says grub should use a password is selected, so you may accidentally skip it.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Create an interactive ks file with passwords for grub and root
2.Proceed to the boot loader screen, and then to the root password screen
In the boot loader screen, the button to enable password checking is not even
checked, nevermind the password is remembered. In the root password screen, the
password is just blank, and it won't let me proceed unless I enter the password
Ideally, it should remember the passwords in the kickstart files, such that
users could e.g. customize package selections for their boxes at install time
without the administrator having to let them know the passwords for the system.
Of course they might then be able to change those passwords, but that's not as
much of a problem as having to tell users the passwords that are only to be
known by whoever manages to open a safe and break the seal of the envelope where
the only copy of the password is stored, after which it must be changed immediately.
This has always been the case (in fact, I'm pretty sure you've even filed it
before). We don't have an uncrypted form of the password, so really can't make
use of it in the UI.
Pretty sure there's not anything new we can do, but I'll let Chris look and see
if he can come up with something clever
I thought I'd filed this before, indeed. It doesn't matter if the password
length is correct in the GUI; in fact, I wouldn't matter at all if a blank
password in the GUI implied the confirmation screen would pop up and ask me
whether to use the password from the ks file, instead of just warning about the
blank password. Simply taking a blank default to imply the ks file password
without warnings would be fine as well; point is to avoid having to re-enter the
password, and dropping even the choice of enabling a boot loader password.
After thinking about this for a while, I don't believe there's really anything
good we can do here. Inferring something from blank UI elements is not behavior
that anyone's going to expect or reasonably guess, and it just seems like
something we shouldn't be doing. If you do need to allow user customizations
through an interactive kickstart file but can't have the user know the password,
you could probably just whip something up in a %post script in a few lines of shell.
*** Bug 258981 has been marked as a duplicate of this bug. ***