eternaltyro / cryptsetup

Since Google code is shuttering...
http://code.google.com/p/cryptsetup
GNU General Public License v2.0
0 stars 0 forks source link

misleading error message from crypt_status() / crypt_activate_by_passphrase() #212

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
using mount.crypt (pam_mount):
As root:
# /sbin/mount.crypt -nvo crypto_name=mydm,keyfile=/dev/stdin,fsk_cipher=none 
file.bin dir < pass.key
### succeeds

As an unprivileged user:
$ /sbin/mount.crypt -nvo crypto_name=mydm,keyfile=/dev/stdin,fsk_cipher=none 
file.bin dir < pass.key
(mtcrypt.c:526): keysize=28 trunc_keysize=32
[....]
crypt_activate_by_passphrase: Invalid argument

This "Invalid argument" is very confusing.

Moreover, while in this specific case log_dbg() isn't triggered (because 
mount.crypt does not set it up), the line:
> Activating volume mydm [keyslot -1] using passphrase.
would not make clear (without looking at the sourcecode) that the passphrase 
actually traversed the fd of all child processes (could be from /bin/mount < 
pass.key) and that it reached libcryptsetup.
Something like "got a passphrase of X characters long", or even "got a non-null 
passphrase: good" (like the keysize log message of mount.crypt) could be better.

In this case, the failure comes from the DM ioctl inside crypt_status().
Actually, without uid 0 dm_backend_init() fails (side note: why don't we return 
immediately ?)
Then r = dm_status_device(cd, name);  == -95 == Unknown error (according to 
strerror() in the context of crypt_status()) [but r may come from as deep as 
dm_status_dmi()]
But since r < 0 && r != -ENODEV the function returns CRYPT_INVALID which, 
inside crypt_activate_by_passphrase(),  becomes -EINVAL, thus "Invalid argument"

I don't know how to deal with strerror() according to the function calls stack, 
but returning a more meaningful message (eg: from the raw return code of 
dm_status_device() ?) could help a bit in this kind of edge cases.

Original issue reported on code.google.com by raphael....@gmail.com on 25 Mar 2014 at 12:53

GoogleCodeExporter commented 9 years ago

I am not a cryptsetup developer,just read the bug report and decided to respond 
since i know a thing or two.

Its not possible to interface with cryptsetup if you are not root privileged.

That amounts to your report as being invalid since you are reporting problems 
when you use cryptsetup without proper privileges.

you should also report here problems you encounter when you use cryptsetup 
directly. Your problems are coming from "mount.crypt" and hence you should 
report the problem to them.

Since its not possible to interface with cryptseup without root privileges,you 
should file a bug report with "mount.crypt" people and tell them they should 
first check if a user is properly privileged before doing anything with 
cryptsetup.Them not doing this is the root cause of misleading and confusing 
errors you are getting.

Original comment by mhogomch...@gmail.com on 27 Mar 2014 at 2:18

GoogleCodeExporter commented 9 years ago
Yes, please report bug for pam_mount. If there is a problem with libcryptsetup, 
I will fix it. But it seems it is just wrong use of it.

(Superuser privilege requirement of device-mapper kernel subsystem, one day it 
will be fixed but it is long way to go... But you should get proper error 
saying "running as non-root user". But application must properly configure 
logging of course. See dm_init_context() which is called in status call. Maybe 
it should return -EPERM error in this case... I'll make not to TODO for this.)

BTW please note that "got a passphrase of X characters long" is security 
problem, you are leaking potential information about password this way. Such 
message must not appear in log or output.

Original comment by gmazyl...@gmail.com on 27 Mar 2014 at 6:37