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.
Description of problem: if you use a poor luks password ssm throws an error but does complete all of the steps up to the encryption point
Version-Release number of selected component (if applicable): 7.0
How reproducible:
Steps to Reproduce:
1. create a couple of disks
2. run ssm create
ssm create -s 1G -n new-lv-name --fstype xfs -p new-pool -e luks /dev/sda /dev/sdb
Physical volume "/dev/sda" successfully created
Physical volume "/dev/sdb" successfully created
Volume group "new-pool" successfully created
Logical volume "new-lv-name" created
Enter passphrase:
Verify passphrase:
Password quality check failed:
The password fails the dictionary check - it is based on a dictionary word
SSM Error (2012): ERROR running command: "cryptsetup -q -y luksFormat /dev/new-pool/new-lv-name"
Actual results:
ssm list
-------------------------------------------------------------------
Device Free Used Total Pool Mount point
-------------------------------------------------------------------
/dev/sda 0.00 KB 1020.00 MB 1.00 GB new-pool
/dev/sdb 1016.00 MB 4.00 MB 1.00 GB new-pool
/dev/vda 8.00 GB PARTITIONED
/dev/vda1 500.00 MB /boot
/dev/vda2 0.00 KB 7.51 GB 7.51 GB rhel
-------------------------------------------------------------------
-----------------------------------------------------
Pool Type Devices Free Used Total
-----------------------------------------------------
new-pool lvm 2 1016.00 MB 1.00 GB 1.99 GB
rhel lvm 1 0.00 KB 7.51 GB 7.51 GB
-----------------------------------------------------
-----------------------------------------------------------------------------
Volume Pool Volume size FS FS size Free Type Mount point
-----------------------------------------------------------------------------
/dev/rhel/root
rhel 6.71 GB xfs 6.70 GB 5.94 GB linear /
/dev/rhel/swap
rhel 820.00 MB linear
/dev/new-pool/new-lv-name
new-pool 1.00 GB linear
/dev/vda1
500.00 MB xfs 496.67 MB 425.54 MB part /boot
-----------------------------------------------------------------------------
Expected results:
If you are going to fail - suggest the luks password check is done before we run anything else?
Additional info:
Setting devel_ack+ since a patch does exist upstream.
However, it seems like writing and encrypting a 10MB file just to test the password is heavy-handed. Looking at the cryptsetup manpage:
RETURN CODES
Cryptsetup returns 0 on success and a non-zero value on error.
Error codes are: 1 wrong parameters, 2 no permission (bad passphrase), 3 out of memory, 4 wrong device specified, 5 device already exists or device is busy.
It seems far more efficient to just catch the "EPERM" return, and re-run cryptsetup so the user can try again.
Thanks,
-Eric
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://access.redhat.com/errata/RHBA-2019:2133
Description of problem: if you use a poor luks password ssm throws an error but does complete all of the steps up to the encryption point Version-Release number of selected component (if applicable): 7.0 How reproducible: Steps to Reproduce: 1. create a couple of disks 2. run ssm create ssm create -s 1G -n new-lv-name --fstype xfs -p new-pool -e luks /dev/sda /dev/sdb Physical volume "/dev/sda" successfully created Physical volume "/dev/sdb" successfully created Volume group "new-pool" successfully created Logical volume "new-lv-name" created Enter passphrase: Verify passphrase: Password quality check failed: The password fails the dictionary check - it is based on a dictionary word SSM Error (2012): ERROR running command: "cryptsetup -q -y luksFormat /dev/new-pool/new-lv-name" Actual results: ssm list ------------------------------------------------------------------- Device Free Used Total Pool Mount point ------------------------------------------------------------------- /dev/sda 0.00 KB 1020.00 MB 1.00 GB new-pool /dev/sdb 1016.00 MB 4.00 MB 1.00 GB new-pool /dev/vda 8.00 GB PARTITIONED /dev/vda1 500.00 MB /boot /dev/vda2 0.00 KB 7.51 GB 7.51 GB rhel ------------------------------------------------------------------- ----------------------------------------------------- Pool Type Devices Free Used Total ----------------------------------------------------- new-pool lvm 2 1016.00 MB 1.00 GB 1.99 GB rhel lvm 1 0.00 KB 7.51 GB 7.51 GB ----------------------------------------------------- ----------------------------------------------------------------------------- Volume Pool Volume size FS FS size Free Type Mount point ----------------------------------------------------------------------------- /dev/rhel/root rhel 6.71 GB xfs 6.70 GB 5.94 GB linear / /dev/rhel/swap rhel 820.00 MB linear /dev/new-pool/new-lv-name new-pool 1.00 GB linear /dev/vda1 500.00 MB xfs 496.67 MB 425.54 MB part /boot ----------------------------------------------------------------------------- Expected results: If you are going to fail - suggest the luks password check is done before we run anything else? Additional info: