Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
DescriptionBill 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
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
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.
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.
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.
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