[dm-crypt] shoulnt "crypt_init_by_name()" fail when the underlying device is no longer available?
.. ink ..
mhogomchungu at gmail.com
Thu Nov 29 20:32:41 CET 2012
> > 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.
> (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
> Hope this helps (I should probably extend API docs with above)
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
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
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
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
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
It has a plug in architecture now and hence adding support for additional
ways of getting keys is trivial.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dm-crypt