Bug 181740

Summary: passwords specified in kickstart file are discarded by interactive mode
Product: [Fedora] Fedora Reporter: Alexandre Oliva <oliva>
Component: anacondaAssignee: Chris Lumens <clumens>
Status: CLOSED CANTFIX QA Contact: Mike McLean <mikem>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: shap
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-01-31 21:55:15 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Alexandre Oliva 2006-02-16 04:50:03 UTC 
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):
anaconda-10.92.4-1

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
twice

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 20:33:46 UTC 
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-21 03:43:31 UTC 
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 21:55:15 UTC 
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 21:06:58 UTC 
*** Bug 258981 has been marked as a duplicate of this bug. ***