> Let say i want to be lazy and only do one check,should checking ifWhich is not exactly correct. If you expect LUKS device, you should check
> "cd" is NULL be sufficient to cover all invalid cases or its
> necessary to do bo checks to be 100% sure.
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.
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
