From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.server123.net (Postfix) with ESMTPS for ; Fri, 4 Jul 2014 18:44:19 +0200 (CEST) Received: by mail-wi0-f177.google.com with SMTP id r20so4190473wiv.16 for ; Fri, 04 Jul 2014 09:44:19 -0700 (PDT) Message-ID: <53B6D9DA.1010406@gmail.com> Date: Fri, 04 Jul 2014 18:44:10 +0200 From: Milan Broz MIME-Version: 1.0 References: <53A89FF3.5020400@gmail.com> <20140623231247.GB15539@agk-dp.fab.redhat.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [dm-crypt] cryptsetup problem with memory allocation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Belisko Marek , Milan Broz , "dm-crypt@saout.de" , Peter Rajnoha , agk@redhat.com On 07/04/2014 05:02 PM, Belisko Marek wrote: > Hi, > > On Tue, Jun 24, 2014 at 1:12 AM, Alasdair G Kergon wrote: >>>> I track it down that malloc fails (ENONMEM) in libdevmapper and then >>>> _dm_check_versions() fails when creating dm task (dmt = >>>> dm_task_create(DM_DEVICE_LIST_VERSIONS). >> >> After updating to the most recent version you are able to use, >> run it under strace and let us see the relevant output (at least the >> failing system call itself, what leads up to it, including all early >> memory-related system calls and DM ioctls) and any environment variables >> set that could modify behaviour. > when update to latest cryptsetup (1.64) I can see different error as with 1.62: > ioctl(6, DM_VERSION, 0x1e340) = -1 EACCES (Permission denied) > So it seems that gcrypt probably drop privileges (as running on > embedded system I'm root)? Just guess, but do you have gcrypt compiled with Posix capabilities? If so, it cannot work. See this comment in cryptsetup gcrypt wrapper (you can workaround it by uncommenting this #if and rebuild cryptsetup) lib/crypto_backend/crypto_gcrypt.c: /* FIXME: If gcrypt compiled to support POSIX 1003.1e capabilities, * it drops all privileges during secure memory initialisation. * For now, the only workaround is to disable secure memory in gcrypt. * cryptsetup always need at least cap_sys_admin privilege for dm-ioctl * and it locks its memory space anyway. */ #if 0 gcry_control (GCRYCTL_DISABLE_SECMEM); crypto_backend_secmem = 0; #else gcry_control (GCRYCTL_SUSPEND_SECMEM_WARN); gcry_control (GCRYCTL_INIT_SECMEM, 16384, 0); gcry_control (GCRYCTL_RESUME_SECMEM_WARN); #endif Milan