Bug 732179 - return code 0 even if device locked
Summary: return code 0 even if device locked
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: cryptsetup-luks
Version: 6.1
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Milan Broz
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On: 711832
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-08-20 09:53 UTC by Patrick C. F. Ernzer
Modified: 2013-03-01 04:10 UTC (History)
15 users (show)

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.
Clone Of: 711832
Environment:
Last Closed: 2011-12-06 17:02:33 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:1688 normal SHIPPED_LIVE cryptsetup-luks bug fix and enhancement update 2011-12-06 00:49:57 UTC

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@redhat.com on 2011-06-08 13:04:22 EDT ---

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

--- Additional comment from mbroz@redhat.com 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@redhat.com 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@fedoraproject.org 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@fedoraproject.org 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@fedoraproject.org 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


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