[pkg-cryptsetup-devel] Bug#552273: Bug#552273: Bug#551540: cryptsetup fails when EUID != UID

[Jonas Meurer]

reassign 552273 libgcrypt11
thanks

Hey,

On 15/01/2010 Milan Broz wrote:
> >> reassign 551540 cryptsetup 2:1.1.0~rc2-1
> 
> >> It seems that "cryptsetup luksOpen" fails when EUID != UID.  In
> >> particular, this happens when it is run by pmount which is suid (I
> >> assume that the reporters above ran pmount as non-root).  If cryptsetup
> >> is run directly, then it works, because necessarily you become root
> >> before running cryptsetup; if I become root before running pmount, then
> >> also everything works.
> 
> Because there are still open bugs, let me explain the real source of problem:
> 
> - in previous versions (cryptsetup <= 1.0.7) gcrypt was used only for plain device
> hash and did not need initialise gcrypt library properly.
> 
> - since 1.1.0* all crypt functions are implemented through gcrypt and
> gcrypt is properly initialised including secure memory (gcry_control (GCRYCTL_INIT_SECMEM...)
> 
> Unfortunately, there is "feature" in libgcrypt which drops some privileges
> after initialisation of that secure memory, in particular
> 
>  - it drops UID if UID and EUID differ
>  - it drops all capabilities if gcrypt is linked to libcap (not an issue in Debian for now)
> 
> Suggested workaround (use own memory allocator) is not possible in FIPS mode,
> and upstream cryptsetup uses gcrypt to be FIPS compliant if needed.
> 
> (pmount workaroud currently uses UID=EUID=0 when calling cryptsetup as workaround AFAIK)
> 
> Anyway, I think that this is bug in libgcrypt, such side effect is not expected when running
> from privileged application like cryptsetup and there is no way how to switch it off by default.
> 
> For more info see upstream cryptsetup bug
> http://code.google.com/p/cryptsetup/issues/detail?id=47
> 
> and also libgcrypt upstream bug ("This is not a bug but a feature.")
> https://bugs.g10code.com/gnupg/issue1181

reassigning this bugreport to libgcrypt, it seems to me that the bug
needs to be fixed there. the relevant upstream bugreport is linked in
milans explanation above.

greetings,
 jonas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-cryptsetup-devel/attachments/20110219/dd2c5197/attachment.pgp>