unable to mount existing ecryptfs file systems

[Michael Borland]

I use Fedora 10. I performed a system updat 6/29, and I am now unable to mount
existing ecryptfs file systems. As a result, all the files are inaccessible.

I'm using kernel 2.6.27.24-170.2.68.fc10.i686 and ecryptfs-utils-75-1.fc10.i386

The following error message appears after I enter the pass phrase:

Error attempting to evaluate mount options: [-22] Invalid argument
Check your system logs for details on why this happened.
Try updating your ecryptfs-utils package, and/or
submit a bug report on https://launchpad.net/ecryptfs

I removed ecryptfs-utils (which was just updated today), and installed version 73-1 from source. This did not resolve the problem.

I also tried several older kernels, 2.6.27.21-170.2.56.fc10.i686 and 2.6.27.19-170.2.35.fc10.i686, but this didn't resolve the problem.

Here are the relevant lines from the /var/log/messages:

May 29 22:39:18 localhost mount.ecryptfs: Could not open library handle
May 29 22:39:18 localhost mount.ecryptfs: Could not open library handle
May 29 22:39:23 localhost mount.ecryptfs: do_hash: PK11_HashBuf() error;
SECFailure = [-1]; PORT_GetError() = [-8128]
May 29 22:39:23 localhost mount.ecryptfs: Error generating passphrase
signature; rc = [-22]
May 29 22:39:23 localhost mount.ecryptfs:
ecryptfs_add_passphrase_key_to_keyring: Error attempting to generate the
passphrase auth tok payload; rc = [-22]

[Michael (michael-redhat-bugs)]

Description of problem:
I performed a system updated today.Starting today (6/29), I am unable to mount ecryptfs file systems.

Version-Release number of selected component (if applicable):
ecryptfs-utils-75-1.fc10.i386
kernel 2.6.27.24-170.2.68.fc10.i686

How reproducible:
Always

Steps to Reproduce:
1. Attempt to mount ecryptfs file system

Actual results:
The following error message appears after I under the pass phrase:

Error attempting to evaluate mount options: [-22] Invalid argument
Check your system logs for details on why this happened.
Try updating your ecryptfs-utils package, and/or
submit a bug report on https://launchpad.net/ecryptfs

Expected results:

File system should be mounted.

Additional info:

I removed ecryptfs-utils (which was just updated today), and installed version 73-1 from source. This did not resolve the problem.

I also tried several older kernels, 2.6.27.21-170.2.56.fc10.i686 and 2.6.27.19-170.2.35.fc10.i686, but this didn't resolve the problem.

[Eric (eric-redhat-bugs)]

(In reply to comment #0)
...
> Error attempting to evaluate mount options: [-22] Invalid argument
> Check your system logs for details on why this happened.
> Try updating your ecryptfs-utils package, and/or
> submit a bug report on https://launchpad.net/ecryptfs

Is there anything in the system logs? (dmesg)

-Eric

[Michael (michael-redhat-bugs)]

Here are the relevant lines from the /var/log/messages:

May 29 22:39:18 localhost mount.ecryptfs: Could not open library handle
May 29 22:39:18 localhost mount.ecryptfs: Could not open library handle
May 29 22:39:23 localhost mount.ecryptfs: do_hash: PK11_HashBuf() error; SECFailure = [-1]; PORT_GetError() = [-8128]
May 29 22:39:23 localhost mount.ecryptfs: Error generating passphrase signature; rc = [-22]
May 29 22:39:23 localhost mount.ecryptfs: ecryptfs_add_passphrase_key_to_keyring: Error attempting to generate the passphrase auth tok payload; rc = [-22]

[Michael Borland (michael-borland)]

Sorry for the typo, my system update was performed on 5/29, not 6/29.

[Michal (michal-redhat-bugs)]

please add output of:
rpm -V ecryptfs-utils

and the command you are using for mount

thanks

[Michael (michael-redhat-bugs)]

# rpm -V ecryptfs-utils
(produces no output)
# rpm -qa | fgrep ecrypt
ecryptfs-utils-75-1.fc10.i386

Relevant line from my fstab:
/home/borland/.secure /home/borland/secure ecryptfs users,key=passphrase,ecryptfs_cipher=aes,ecryptfs_key_bytes=32,ecryptfs_passthrough=n,noauto 0 0

I then mount from by user account with
% mount .secure

Thanks--Michael

[Michal (michal-redhat-bugs)]

could you please check your version of nss package and if you've updated this package recently?

[Michal (michal-redhat-bugs)]

I was able to reproduce this. Complete messages from your syslog would be:
May 29 22:39:18 localhost mount.ecryptfs: Could not open library handle: /usr/lib64/ecryptfs/libecryptfs_key_mod_passphrase.so: failed to map segment from shared object: Resource temporarily unavailable
...
May 29 22:39:23 localhost mount.ecryptfs: do_hash: PK11_HashBuf() error;
SECFailure = [-1]; PORT_GetError() = [-8128] : libsoftokn3.so: failed to map segment from shared object: Resource temporarily unavailable

both problems are because dlopen fails

well... originally, /sbin/mount.ecryptfs had setuid root permission, I've changed it recently, because I've been told it's required only for /sbin/mount.ecryptfs_private. If you change it back to setuid, it will work. So you can use:
chmod 4755 /sbin/mount.ecryptfs
as workaround before I investigate this problem more deeply.

[Michal (michal-redhat-bugs)]

OK, I've found the problem:

mount helper locks it's memory using mlockall(MCL_FUTURE) to prevent memory containing secret data being swapped out. But non-privileged user is limited to how much memory he/she can lock at most. man mlockall:

"If MCL_FUTURE has been specified, then a later system call (e.g., mmap(2), sbrk(2), malloc(3)), may fail if it would cause the number of locked bytes to exceed the permitted maximum."

Without locking memory, it works

[Michael (michael-redhat-bugs)]

My nss packages are as follows:
nss-tools-3.12.2.0-5.fc10.i386
nss_compat_ossl-0.9.5-3.fc10.i386
nss-devel-3.12.2.0-5.fc10.i386
nss_db-2.2-43.fc10.i386
nss-3.12.2.0-5.fc10.i386
nss_ldap-264-1.fc10.i386

Last update was May 5.

The chmod 4755 /sbin/mount.ecryptfs workaround solves the problem for me.

Thanks!

--Michael

[Michal Hlavinka (mhlavink)]

OK, I've found the problem:

mount helper locks it's memory using mlockall(MCL_FUTURE) to prevent memory
containing secret data being swapped out. But non-privileged user is limited to
how much memory he/she can lock at most. man mlockall:

"If MCL_FUTURE has been specified, then a later system call (e.g., mmap(2),
sbrk(2), malloc(3)), may fail if it would cause the number of locked bytes to
exceed the permitted maximum."

Without locking memory, it works

[Michal (michal-redhat-bugs)]

unfortunately, this is not a bug completely, your mount options in fstab are not complete

real now it designed to work this way:
1) as root, mount your private directory
2) run mount, which will return mount options used including key signature(s)
3) put this options to /etc/fstab

when mounting, do:
ecryptfs-add-passphrase --fnek (if you are not using file name encryption, don't use "--fnek")
mount -i

but this is bug, because:
mlockall code is somehow broken
and this design seems little bit odd

[Dustin Kirkland  (kirkland)]

Michal-

How do you propose that we solve this problem?

:-Dustin

[Tyler Hicks (tyhicks)]

Hi Michal - I'm going to take over this one in the upstream tracker so that I won't forget about it. Do you have any update on this?

[Michal Hlavinka (mhlavink)]

> How do you propose that we solve this problem?

it's difficult question...

> Do you have any update on this?

not too much...

first - mount.ecryptfs does not work because of mlock limit, it means only required parts should be locked, not whole memory. I was thinking about something like safe_malloc and safe_free as used for example in cryptsetup (iirc)

second - when I've removed suid bit from mount.ecryptfs in Fedora, it seems mount.ecryptfs is quite useless, because only root can use it. Even if user have all options in /etc/fstab, he has not enough privileges to use mount.ecryptfs, only add keys (ecryptfs-add-... or with mount.ecryptfs if other modules than passphrase are needed, go to mount: permission denied and use mount -i). This seems quite broken for me... if we already have mount.ecryptfs and mount.ecryptfs_private, which can (after not completely easy re-configuration) mount any owned directory... this design really seems broken. So I suggest: use mount.ecryptfs only for generating options, adding key to keyring,... and mount.ecryptfs_private only for mounting (suid, with owned directory check). This will allow to use mount.ecryptfs in/instead of other shell scripts, which iirc were created only because mount.ecryptfs was broken and too scary.

[Bug (bug-redhat-bugs)]

This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 10 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

[Michal (michal-redhat-bugs)]

updating version, problem still exists in F-12. (When this problem is fixed, I'll fix it in all not EOLed fedora versions)

[Bug (bug-redhat-bugs)]

This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 12 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

[Felix Lechner (felix.lechner)]

I think this bug is back in Maverick.

Just updated kernel to linux-image-2.6.35-23-generic, version 2.6.35-23.40. Tools are ecryptfs-utils, version 83-0ubuntu3.

From syslog:

Nov 23 12:54:19 mount.ecryptfs: do_hash: PK11_HashBuf() error; SECFailure = [-1]; PORT_GetError() = [-8128]
Nov 23 12:54:19 mount.ecryptfs: Error generating passphrase signature; rc = [-22]
Nov 23 12:54:19 mount.ecryptfs: ecryptfs_add_passphrase_key_to_keyring: Error attempting to generate the passphrase auth tok payload; rc = [-22]

[Bug (bug-redhat-bugs)]

Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

[Tuomas Heino (iheino+ub)]

Potential ways to work around the mlock issue:
- in case the system is using only encrypted swap, don't require mlock (possible race condition issues with this approach)
- set proper hard/soft limits in /etc/security/limits.conf (or /etc/security/limits.d or equivalent place for ulimits)

Proper value for memlock / ulimit -l seems to be somewhere between 128 and 32768.

[Dustin Kirkland  (kirkland)]

@Michal et al., what is 'ulimit -a' on the Fedora or other systems where this bug is reproducible?

[Dustin Kirkland  (kirkland)]

I'm not able to reproduce this problem here. This should be fixed with appropriate limits in /etc/security/limits.conf. Marking wont-fix for now. Thanks!

[Dustin Kirkland  (kirkland)]

Note that the RH bug https://bugzilla.redhat.com/show_bug.cgi?id=503261 is wont-fix as well.

[Michal Hlavinka (mhlavink)]

$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 31475
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 1024
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited

how to reproduce this:
as root:
echo "/tmp/1 /tmp/2 ecryptfs key=passphrase:passphrase_passwd=heslo,ecryptfs_key_bytes=16,ecryptfs_cipher=aes,no_sig_cache,verbosity=0,users,noauto 0 0" >>/etc/fstab

as ordinary user:
mkdir /tmp/1 /tmp/2
mount /tmp/2

-> syslog: mount.ecryptfs: Could not open library handle

> Note that the RH bug https://bugzilla.redhat.com/show_bug.cgi?id=503261 is wont-fix as well.

it was closed wont-fix by a bot, because it was reported against Fedora version that is no longer
supported. I did not fix it because this design does not allow any worthy solution and I did not
get any answer to my comment #5.

PS: I don't read all launchpad emails, so if you ask me a question in launchpad, ping me on irc. Thanks

[insaner (insaner)]

any advances on this? i use fedora (14) as my main os and cannot use ecryptfs.. whereas ubuntu has had no issues whatsoever in the last few versions

[insaner (insaner)]

tried the ulimit workaround,
ulimit -l 32000
then mount,

then

ulimit -l 256
then mount,

but neither worked.. it was originally set to unlimited.

all 3 give me:

Select key type to use for newly created files:
 1) passphrase
 2) openssl
 3) pkcs11-helper
 4) tspi
Selection: 1
Passphrase:
Select cipher:
 1) aes: blocksize = 16; min keysize = 16; max keysize = 32 (loaded)
 2) des3_ede: blocksize = 8; min keysize = 24; max keysize = 24 (not loaded)
 3) cast6: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded)
 4) cast5: blocksize = 8; min keysize = 5; max keysize = 16 (not loaded)
Selection [aes]:
Select key bytes:
 1) 16
 2) 32
 3) 24
Selection [16]:
Error attempting to evaluate mount options: [-22] Invalid argument
Check your system logs for details on why this happened.
Try updating your ecryptfs-utils package, and/or
submit a bug report on https://launchpad.net/ecryptfs

/var/log/messages:

2012-12-16T15:04:28.268262-04:00 localhost mount.ecryptfs: Key module [openssl] does not have a subgraph transition node; attempting to build a linear subgraph from its parameter list
2012-12-16T15:04:28.268324-04:00 localhost mount.ecryptfs: Key module [openssl] has empty parameter list
2012-12-16T15:04:28.268346-04:00 localhost mount.ecryptfs: Key module [pkcs11-helper] does not have a subgraph transition node; attempting to build a linear subgraph from its parameter list
2012-12-16T15:04:28.268369-04:00 localhost mount.ecryptfs: Key module [pkcs11-helper] has empty parameter list