Bug 599617

Summary: libcryptsetup activate_by* library calls should support NULL as device name
Product: Red Hat Enterprise Linux 6 Reporter: Milan Broz <mbroz>
Component: cryptsetup-luksAssignee: Milan Broz <mbroz>
Status: CLOSED CURRENTRELEASE QA Contact: Release Test Team <release-test-team-automation>
Severity: medium Docs Contact:
Priority: low    
Version: 6.0CC: agk, atodorov, dwysocha, huzaifas, mbroz, mganisin, prockai, pvrabec
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: cryptsetup-luks-1.1.2-1.el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-11-10 20:05:00 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:
Attachments:
Description Flags
api-test log none

Description Milan Broz 2010-06-03 15:52:28 UTC
Description of problem:
Documented use of activation_by* (like activation_by_passphrase) is that with device name == NULL it should jusr run verification but not device activation.

These calls are currently wrongly implemented in this case, in some cases library can even crash.

Fixed upstream
http://code.google.com/p/cryptsetup/source/detail?r=262#

Version-Release number of selected component (if applicable):
cryptsetup-luks-1.1.1-1.el6

Comment 3 RHEL Program Management 2010-06-03 16:03:14 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

Comment 4 Huzaifa S. Sidhpurwala 2010-06-04 01:49:19 UTC
I agree,
Currently i have to activate and deactivate the device to verify its luks password which is wrong.
device == NULL should just verify the password without actually activating the device, which would save a lot of housekeeping in deactivating etc.

Comment 5 Milan Broz 2010-06-07 08:26:25 UTC
Fixed in cryptsetup-luks-1.1.2-1.el6.

Comment 7 Alexander Todorov 2010-07-06 10:25:25 UTC
Hi Milan,
I've executed the patched api-test binary from the cryptsetup-luks-1.1.2-1.el6.src.rpm against the binary package built from the same SRPM. 

Here is the test output for the test cases added by the patch:

 [(fail)   ,AddDevicePlain:553] crypt_activate_by_volume_key(cd, NULL, key, key_size, 0) [cannot verify key with plain]

 [(fail)   ,AddDevicePlain:566] crypt_activate_by_passphrase(cd, NULL, CRYPT_ANY_SLOT, passphrase, strlen(passphrase), 0) [cannot verify passphrase with plain]

 [(success),UseLuksDevice:624] crypt_activate_by_volume_key(cd, NULL, key, key_size, 0)

 [(equal)  ,AddDeviceLuks:700] 1 == crypt_keyslot_add_by_volume_key(cd, 1, key, key_size, KEY1, strlen(KEY1))
 [(success),AddDeviceLuks:701] _prepare_keyfile(KEYFILE1, KEY1)
 [(success),AddDeviceLuks:702] _prepare_keyfile(KEYFILE2, KEY2)
 [(equal)  ,AddDeviceLuks:703] 2 == crypt_keyslot_add_by_keyfile(cd, 2, KEYFILE1, 0, KEYFILE2, 0)
 [(fail)   ,AddDeviceLuks:704] crypt_activate_by_keyfile(cd, CDEVICE_2, CRYPT_ANY_SLOT, KEYFILE2, strlen(KEY2)-1, 0) [key mismatch]
   => errno -1, errmsg: No key available with this passphrase.
 [(equal)  ,AddDeviceLuks:705] 2 == crypt_activate_by_keyfile(cd, NULL, CRYPT_ANY_SLOT, KEYFILE2, 0, 0)
 [(equal)  ,AddDeviceLuks:706] 2 == crypt_activate_by_keyfile(cd, CDEVICE_2, CRYPT_ANY_SLOT, KEYFILE2, 0, 0)
 [(success),AddDeviceLuks:707] crypt_keyslot_destroy(cd, 1)
 [(success),AddDeviceLuks:708] crypt_keyslot_destroy(cd, 2)
 [(success),AddDeviceLuks:709] crypt_deactivate(cd, CDEVICE_2)


This looks correct as far as I can see. Will attach the full test log. 

Is this enough to call this bug VERIFIED?

Comment 8 Alexander Todorov 2010-07-06 10:26:54 UTC
Created attachment 429731 [details]
api-test log

Comment 9 Milan Broz 2010-07-07 07:57:36 UTC
(In reply to comment #7)

> Is this enough to call this bug VERIFIED?
yes.
(patch in spec included patch for internal api-test to cover this)

Comment 10 releng-rhel@redhat.com 2010-11-10 20:05:00 UTC
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.