RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1030626 - forces user creation in kickstart
Summary: forces user creation in kickstart
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: anaconda
Version: 7.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Brian Lane
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-11-14 20:11 UTC by Bill Nottingham
Modified: 2015-03-05 13:56 UTC (History)
5 users (show)

Fixed In Version: anaconda-19.31.82-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-03-05 13:56:32 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:0312 0 normal SHIPPED_LIVE anaconda bug fix and enhancement update 2015-03-05 17:35:22 UTC

Description Bill Nottingham 2013-11-14 20:11:12 UTC 
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-15 00:11:08 UTC 
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 18:08:47 UTC 
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 20:03:01 UTC 
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 10:25:32 UTC 
Isn't "rootpw --iscrypted !!" an acceptable workaround?
Comment 7 Brian Lane 2014-08-01 22:40:14 UTC 
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 13:56:32 UTC 
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.

https://rhn.redhat.com/errata/RHBA-2015-0312.html
Note You need to log in before you can comment on or make changes to this bug.