1141871 – poor luks password results in ssm throwing an error but completing all steps prior to encryption.

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 1141871 - poor luks password results in ssm throwing an error but completing all steps prior to encryption.

Summary: poor luks password results in ssm throwing an error but completing all steps ...

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 7
Classification:	Red Hat
Component:	system-storage-manager
Sub Component:
Version:	7.0
Hardware:	Unspecified
OS:	Unspecified
Priority:	unspecified
Severity:	unspecified
Target Milestone:	rc
Target Release:	---
Assignee:	Lukáš Czerner
QA Contact:	Boyang Xue
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+	depends on / blocked

Reported:	2014-09-15 15:51 UTC by cmilsted
Modified:	2019-08-06 12:55 UTC (History)
CC List:	8 users (show)
Fixed In Version:
Doc Type:	If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:	2019-08-06 12:55:09 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Red Hat Product Errata	RHBA-2019:2133	0	None	None	None	2019-08-06 12:55:13 UTC

Description cmilsted 2014-09-15 15:51:28 UTC

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:

Comment 3 Jan Tulak 2018-01-17 13:03:57 UTC

This issue should be resolved in this commit, currently sitting in devel branch: https://github.com/system-storage-manager/ssm/commit/72437ae0ed6d1d3d26841bb8e560934c5cff8cc9

I will get it into RHEL with the next SSM release, so RHEL 7.6 will have it fixed for sure.

Comment 4 Eric Sandeen 2018-03-26 17:15:02 UTC

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

Comment 6 Jan Tulak 2018-08-10 12:39:37 UTC

Upstream solution was changed to a more acceptable one in the new release.

Comment 14 errata-xmlrpc 2019-08-06 12:55:09 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://access.redhat.com/errata/RHBA-2019:2133

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