Bug 732179

Summary: return code 0 even if device locked
Product: Red Hat Enterprise Linux 6 Reporter: Patrick C. F. Ernzer <pcfe>
Component: cryptsetup-luksAssignee: Milan Broz <mbroz>
Status: CLOSED ERRATA QA Contact: Release Test Team <release-test-team-automation>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.1CC: agk, atodorov, dwysocha, lvm-team, mbroz, msnitzer, msvoboda, opensource, pholica, pjones, prajnoha, prockai, pvrabec, whulbert, zkabelac
Target Milestone: rcKeywords: Regression
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: cryptsetup-luks-1.2.0-6.el6 Doc Type: Bug Fix
Doc Text:
Prior to this update, several directives were missing in cryptsetup status command implementation. Therefore, the cryptsetup status command always returned the exit code 0 when verifying the status of a mapped device. To fix this issue, the code has been modified. The cryptsetup status command now returns the 0 value only if the device checked is active.
Story Points: ---
Clone Of: 711832 Environment:
Last Closed: 2011-12-06 17:02:33 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 711832    
Bug Blocks:    

Description Patrick C. F. Ernzer 2011-08-20 09:53:06 UTC
Same problem as under F15 but under RHEL 6.1 with cryptsetup-luks-1.2.0-3.el6_1.2.x86_64

Could you please port the patch from F15 to RHEL6?

+++ This bug was initially created as a clone of Bug #711832 +++

Description of problem:
before F15, I could do this
cryptsetup status luks-${UUID}
if [ $? = 0 ]; then
        echo "Device already unlocked"
else
        echo "need to unlock device"
        cryptsetup luksOpen /dev/BANANA luks-${UUID}
fi

But since I installed F15 x86_64 on this box, cryptsetup status always has a return code of 0

Version-Release number of selected component (if applicable):
cryptsetup-luks-1.2.0-2.fc15.x86_64

How reproducible:
always

Steps to Reproduce:
[root@karhu ~]# cryptsetup status luks-SOMETHING
/dev/mapper/luks-SOMETHING is inactive.
[root@karhu ~]# echo $?
0
[root@karhu ~]# cryptsetup luksOpen /dev/BANANA luks-SOMETHING
Enter passphrase for /dev/BANANA: 
[root@karhu ~]# cryptsetup status luks-SOMETHING
/dev/mapper/luks-SOMETHING is active.
  type:  LUKS1
  cipher:  aes-cbc-essiv:sha256
  keysize: 256 bits
  device:  /dev/BANANA
  offset:  2056 sectors
  size:    104855544 sectors
  mode:    read/write
[root@karhu ~]# echo $?
0
  
Actual results:
exit code is 0 also when device is still locked

Expected results:
exit code 0 only when device is unlocked

Additional info:
obviously BANANA and SOMETHING is me replacing the UUID and device path by hand for the bug report

--- Additional comment from mbroz on 2011-06-08 13:04:22 EDT ---

Hm. yes, it should return error code if device dosn't exist.

--- Additional comment from mbroz on 2011-06-08 13:14:01 EDT ---

Just one line fix. I'll plan to update cryptsetup to 1.3.1 version in F15, so I'll add this patch too.

Thanks for report.

--- Additional comment from mbroz on 2011-06-22 10:44:04 EDT ---

Updated cryptsetup-luks-1.3.1-2.fc15 with patch for this problem as well.

--- Additional comment from updates on 2011-06-22 10:48:11 EDT ---

cryptsetup-luks-1.3.1-2.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/cryptsetup-luks-1.3.1-2.fc15

--- Additional comment from updates on 2011-06-23 23:36:38 EDT ---

Package cryptsetup-luks-1.3.1-2.fc15:
* should fix your issue,
* was pushed to the Fedora 15 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing cryptsetup-luks-1.3.1-2.fc15'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/cryptsetup-luks-1.3.1-2.fc15
then log in and leave karma (feedback).

--- Additional comment from updates on 2011-06-26 14:48:38 EDT ---

cryptsetup-luks-1.3.1-2.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 2 Milan Broz 2011-08-26 13:56:43 UTC
This is quite trivial fix, it do not interfere with FIPS part and in fact it is regression to 6.0 released version (6.1 is broken though as well).

I think we should respin errata for 6.2 here - easy to test, no risk.

Comment 3 Milan Broz 2011-08-29 11:17:32 UTC
Fixed in
cryptsetup-luks-1.2.0-6.el6

Comment 4 Milan Broz 2011-08-29 11:25:34 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Previously, cryptsetup status command returns exit code 0 always.
Exit code for status command was fixed, so 0 is returned only if device is really active.

Comment 6 Pavel Holica 2011-09-05 11:40:54 UTC
Reproduced on RHEL6.1 x86_64 Server GA, cryptsetup-luks-1.2.0-3.el6
Verified on RHEL6.2-20110905.n.0 x86_64 Server cryptsetup-luks-1.2.0-6.el6

Comment 7 Miroslav Svoboda 2011-10-04 15:25:30 UTC
    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1,2 +1 @@
-Previously, cryptsetup status command returns exit code 0 always.
+Prior to this update, several directives were missing in cryptsetup status command implementation. Therefore, the cryptsetup status command always returned the exit code 0 when verifying the status of a mapped device. To fix this issue, the code has been modified. The cryptsetup status command now returns the 0 value only if the device checked is active.-Exit code for status command was fixed, so 0 is returned only if device is really active.

Comment 8 errata-xmlrpc 2011-12-06 17:02:33 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.

http://rhn.redhat.com/errata/RHBA-2011-1688.html