Bug 181740 - passwords specified in kickstart file are discarded by interactive mode
passwords specified in kickstart file are discarded by interactive mode
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Chris Lumens
Mike McLean
Depends On:
  Show dependency treegraph
Reported: 2006-02-15 23:50 EST by Alexandre Oliva
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-01-31 16:55:15 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Alexandre Oliva 2006-02-15 23:50:03 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):

How reproducible:
Every time

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
Actual results:
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

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

Additional info:
Comment 1 Jeremy Katz 2006-02-20 15:33:46 EST
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
Comment 2 Alexandre Oliva 2006-02-20 22:43:31 EST
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.
Comment 3 Chris Lumens 2007-01-31 16:55:15 EST
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.
Comment 4 Chris Lumens 2007-08-28 17:06:58 EDT
*** Bug 258981 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.