Bug 1030626 - forces user creation in kickstart
forces user creation in kickstart
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: anaconda (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Brian Lane
Release Test Team
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2013-11-14 15:11 EST by Bill Nottingham
Modified: 2015-03-05 08:56 EST (History)
5 users (show)

See Also:
Fixed In Version: anaconda-19.31.82-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-03-05 08:56:32 EST
Type: Bug
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 Bill Nottingham 2013-11-14 15:11:12 EST
Description of problem:

I have a kickstart with:

rootpw --lock

It's intended for a cloud image.

Anaconda stops during installation (virt-install, presumably also with livemedia-creator or oz) and forces me to create a user

Version-Release number of selected component (if applicable):

20131114 nightly
Comment 2 Brian Lane 2013-11-14 19:11:08 EST
You need to have either root or a user defined (or both). spins typically setup root with a password and then remove it in %post, you could setup a password and then in %post lock it with passwd -l
Comment 3 Matthew Miller 2013-12-04 13:08:47 EST
Brian, could you reconsider? Given the security issue with not having a locked password, we'd _really_ like the main command to say "locked" and not depend on %post.

I can envision non-cloud use cases for this as well, where the root password should be locked and no users created, because user accounts are provided by a network service and root access by sudo. This is a common scenario in large university deployments, for example.
Comment 4 David Cantrell 2013-12-16 15:03:01 EST
I'm moving this one to rhel-7.1.0? for now.  I understand the use case, but I'm wondering if should expose the functionality requested through a different command so it is more obvious for use creating cloud images.  I feel we may be setting up non-cloud users for potentially locking themselves out of systems if they accidentally add 'rootpw --lock' and don't also create a user account.  That's sort of the thing we want to prevent in general.
Comment 5 Stephan Wiesand 2013-12-18 05:25:32 EST
Isn't "rootpw --iscrypted !!" an acceptable workaround?
Comment 7 Brian Lane 2014-08-01 18:40:14 EDT
I've sent a patch to the list for comment. After pondering this, I think a kickstart with rootpw --lock is safe enough. It is something that they user has done explicitly, and if they did it on accident it's easy enough for them to edit their kickstart and not do it again.
Comment 10 errata-xmlrpc 2015-03-05 08:56:32 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


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