Bug 1030626
| Summary: | forces user creation in kickstart | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Bill Nottingham <notting> |
| Component: | anaconda | Assignee: | Brian Lane <bcl> |
| Status: | CLOSED ERRATA | QA Contact: | Release Test Team <release-test-team-automation> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.0 | CC: | atodorov, borgan, mattdm, rvokal, stephan.wiesand |
| Target Milestone: | rc | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | anaconda-19.31.82-1 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-03-05 13:56:32 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Bill Nottingham
2013-11-14 20:11:12 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 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. Isn't "rootpw --iscrypted !!" an acceptable workaround? 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 |