[dm-crypt] shoulnt "crypt_init_by_name()" fail when the underlying device is no longer available?

[dm-crypt] shoulnt "crypt_init_by_name()" fail when the underlying device is no longer available?

[.. ink ..]

[-- Attachment #1: Type: text/plain, Size: 1267 bytes --]

test using cryptsetup version 1.5.1

simple test:
1. open a mapper against a device.

2 call crypt_init_by_name() on the mapper and the call return "0" to mean
success,this is expected.

3.Unplug the device.

4.call the function again and it still return "0" to mean success,shouldnt
it fail since the underlying device is no longer available?

Simple test to show this:

open a mapper against a device:
root@mtz ink]# cryptsetup luksOpen /dev/sdc6 sdc6
Enter passphrase for /dev/sdc6:

run the "test" program on the mapper and results are below( source code
below )
[root@mtz ink]# ./test /dev/mapper/sdc6
pass1
pass2

unplugged the device and rerun the test again and the results are below.
[root@mtz ink]# ./test /dev/mapper/sdc6
pass1
fail2
[root@mtz ink]#


source code of the test program:


#include<libcryptsetup.h>

int main( int argc,char * argv[] )
{
    const char * path = argv[ 1 ] ;
    struct crypt_device * cd;

    if( crypt_init_by_name( &cd,path ) < 0 ){
        puts( "fail1" ) ;
        crypt_free( cd ) ;
        return 1 ;
    }else{
        puts( "pass1" ) ;
    }

    const char * e = crypt_get_device_name( cd ) ;

    if( e ){
        puts( "pass2" ) ;
    }else{
        puts( "fail2" ) ;
    }

    crypt_free( cd ) ;

    return 0 ;
}

[-- Attachment #2: Type: text/html, Size: 1585 bytes --]

Re: [dm-crypt] shoulnt "crypt_init_by_name()" fail when the underlying device is no longer available?

[Milan Broz]

On 11/27/2012 11:26 PM, .. ink .. wrote:
> 
> test using cryptsetup version 1.5.1
> 
> simple test:
> 1. open a mapper against a device.
> 
> 2 call crypt_init_by_name() on the mapper and the call return "0" to mean success,this is expected.
> 
> 3.Unplug the device.
> 
> 4.call the function again and it still return "0" to mean success,shouldnt it fail since the underlying device is no longer available?

No it should not. It is explained in API doc:
http://wiki.cryptsetup.googlecode.com/git/API/libcryptsetup_8h.html#a99bc4160e7afacfba1d2c5ee6dbaf3be

"In case device points to active LUKS device but header load fails, context device type
is set to NULL and 0 is returned as if it were successful.
Context with NULL device type can only be deactivated by crypt_deactivate"

So the only think you can do here is deactivate device-mapper device
(which explains why it is needed).

Milan

Re: [dm-crypt] shoulnt "crypt_init_by_name()" fail when the underlying device is no longer available?

[.. ink ..]

[-- Attachment #1: Type: text/plain, Size: 1241 bytes --]

No it should not. It is explained in API doc:

>
> http://wiki.cryptsetup.googlecode.com/git/API/libcryptsetup_8h.html#a99bc4160e7afacfba1d2c5ee6dbaf3be
>
> "In case device points to active LUKS device but header load fails,
> context device type
> is set to NULL and 0 is returned as if it were successful.
> Context with NULL device type can only be deactivated by crypt_deactivate"
>
> So the only think you can do here is deactivate device-mapper device
> (which explains why it is needed).
>
>
So,this function can be used to check if the underlying device is present
or not.Good to know,it will be nice if the docs could say this.

The does clearly states the behavior,and i missed it somehow,my bad.

But why does this function behave this way though? Docs states this
behavior but it doesnt say why and this gives inconsistent behavior.I
always though checking for return value is sufficient to give indication if
i should proceed or bail out,it almost became automatic.It looks like with
this function,i should not check the return value but "cd".

Let say i want to be lazy and only do one check,should checking if "cd" is
NULL be sufficient to cover all invalid cases or its necessary to do bo
checks to be 100% sure.

>  Milan
>

[-- Attachment #2: Type: text/html, Size: 1915 bytes --]

Re: [dm-crypt] shoulnt "crypt_init_by_name()" fail when the underlying device is no longer available?

[Milan Broz]

On 11/28/2012 07:29 PM, .. ink .. wrote:
>     http://wiki.cryptsetup.googlecode.com/git/API/libcryptsetup_8h.html#a99bc4160e7afacfba1d2c5ee6dbaf3be
> 
>     "In case device points to active LUKS device but header load fails, context device type
>     is set to NULL and 0 is returned as if it were successful.
>     Context with NULL device type can only be deactivated by crypt_deactivate"
> 
>     So the only think you can do here is deactivate device-mapper device
>     (which explains why it is needed).
> 
>  
> So,this function can be used to check if the underlying device is present or not.Good to know,it will be nice if the docs could say this.

In correctly (desktop) configured system this should not happen, because
e.g. udisks daemon will react to underlying device "remove" event and
will tear down all remaining top-level devices.
(cryptsetup here provides here just low-level support for it)

It is similar to MD raid5 device, where 2 or more devices disappeared
- md raid device is visible but not in operating state anymore.

> But why does this function behave this way though? Docs states this
> behavior but it doesnt say why and this gives inconsistent behavior.I
> always though checking for return value is sufficient to give
> indication if i should proceed or bail out,it almost became
> automatic.It looks like with this function,i should not check the
> return value but "cd".

You can initialize context 2 ways

1) from the device header on disk (LUKS, in future from other on-disk formats)
	crypt_init(&context, device)
		- no info about format yet, only initial "device ok" check
	crypt_load(context, [FORMAT])
		- either fail (no header, wrong params) or correctly initialized header

2) from already active DM device in kernel.
	crypt_init_by_name(&context, DM-active-name) or

	- if active DM device is not crypt or verity device, it will fail.
	- if active device is crypt or verity, but it uses unknown type
	(from DM-UUID) or the format requires initialization from on-disk
	header and that header is not readable (e.g. disappeared device)
	context is initialized but without type
	(=> the same situation as after crypt_init() before crypt_load())
	- otherwise you have full context initialized

On the other hand, with explicit header device
	crypt_init_by_name_and_header(&context, DM-active-name, device with header)

	it should fail if header device is not NULL and is not available anymore

It is a little bit confusing, but my intention was to allow basic initialization
even when you have no longer header available or if e.g. on-disk header
is encrypted (Truecrypt uses this for example) and you want just
read some info about active device or deactivate it (without providing password again).

> Let say i want to be lazy and only do one check,should checking if
> "cd" is NULL be sufficient to cover all invalid cases or its
> necessary to do bo checks to be 100% sure.

Which is not exactly correct. If you expect LUKS device, you should check
after crypt_init_by_name that you really get LUKS context and not e.g. PLAIN
(using crypt_get_type()). (But this check should be present in all LUKS API
functions, so you just get "not supported" error later if context is wrong.)

Hope this helps (I should probably extend API docs with above)
Milan

Re: [dm-crypt] shoulnt "crypt_init_by_name()" fail when the underlying device is no longer available?

[.. ink ..]

[-- Attachment #1: Type: text/plain, Size: 2921 bytes --]

> > Let say i want to be lazy and only do one check,should checking if
> > "cd" is NULL be sufficient to cover all invalid cases or its
> > necessary to do bo checks to be 100% sure.
>
> Which is not exactly correct. If you expect LUKS device, you should check
> after crypt_init_by_name that you really get LUKS context and not e.g.
> PLAIN
> (using crypt_get_type()). (But this check should be present in all LUKS API
> functions, so you just get "not supported" error later if context is
> wrong.)
>
> Hope this helps (I should probably extend API docs with above)
> Milan
>

Thanks for the long explanation.

I support both LUKS and PLAIN volumes in my program as "first class
citizen" and problem seem to be there only in PLAIN volumes,when i further
look into this,it looks like LUKS volumes behave as expected.
"crypt_init_by_name()" failed on LUKS volumes when the underlying device
disappear.

The problem is with PLAIN volumes,"crypt_init_by_name()"
pass,"crypt_get_active_device()" pass,"crypt_status()" return "CRYPT_BUSY"
instead of "CRYPT_INVALID" and hence a pass in my code
paths,"crypt_get_type()" return "PLAIN" and hence a pass in my code
paths,looking at the flow of my program,the only function i know so far
that will catch this is "crypt_get_device_name()" and hence this is the
function i have chosen to check if the underlying device disappeared.

docs do not say "crypt_get_device_name()" will return NULL if the
underlying device disappeared or on any other error and hence and i am
depending on undefined behavior here.Can i depend on this behavior? can it
be documented.

I build KDE from sources and i have it in a non standard location and i
have so far failed to get the polkit authorization thing working and hence
everything that depends on polkit is broken in my system and i dont use
them.

because of this,i have created another tool,zuluMount to work around my
inability to get polkit working and i have decided to bundle it with
zuluCrypt to share it with the world :-)

zuluMount is a disk mount/unmount tool and it does what udisks and friends
do  but it adds a few things.

It doesnt use dbus or polkit authorization mechanism.Some like me may find
this useful.
It gives uses an option to choose mount point.
It can manage manage PLAIN volumes as well as LUKS volumes but in the case
of zuluMount,they must be in devices.zuluCrypt can still make them when
they are in files too.

Below features are shared by both zuluMount and zuluCrypt.
As far as i know, all GUI tools deal with LUKS volumes only and only with
"naked" passphrases. zuluMount and zuluCrypt allow the use of "naked
passphrases",a combination of "naked passphrases" and keyfiles,keyfiles and
lastly GPG encrypted keyfiles.

Both of zuluCrypt and zuluMount can get keys from gnome keyring and kde
kwallet.

It has a plug in architecture now and hence adding support for additional
ways of getting keys is trivial.

[-- Attachment #2: Type: text/html, Size: 3515 bytes --]