Bug 1141871

Summary: poor luks password results in ssm throwing an error but completing all steps prior to encryption.
Product: Red Hat Enterprise Linux 7 Reporter: cmilsted
Component: system-storage-managerAssignee: Lukáš Czerner <lczerner>
Status: CLOSED ERRATA QA Contact: Boyang Xue <bxue>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.0CC: agk, esandeen, lczerner, nobody, prajnoha, rhandlin, xzhou, zkabelac
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-08-06 12:55:09 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 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