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.

Bug 732179

Summary:	return code 0 even if device locked
Product:	Red Hat Enterprise Linux 6	Reporter:	Patrick C. F. Ernzer <pcfe>
Component:	cryptsetup-luks	Assignee:	Milan Broz <mbroz>
Status:	CLOSED ERRATA	QA Contact:	Release Test Team <release-test-team-automation>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	6.1	CC:	agk, atodorov, dwysocha, lvm-team, mbroz, msnitzer, msvoboda, opensource, pholica, pjones, prajnoha, prockai, pvrabec, whulbert, zkabelac
Target Milestone:	rc	Keywords:	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