unable to mount existing ecryptfs file systems

Reported by Michael Borland on 2009-05-30
50
This bug affects 10 people
Affects Status Importance Assigned to Milestone
eCryptfs
Low
Unassigned
ecryptfs-utils (Fedora)
In Progress
Unknown

Bug Description

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]

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

Michal Hlavinka (mhlavink) wrote :

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

Changed in ecryptfs:
assignee: nobody → Michal Hlavinka (mhlavink)
status: New → Confirmed
Changed in ecryptfs-utils (Fedora):
status: Unknown → In Progress
Changed in ecryptfs:
importance: Undecided → High
Dustin Kirkland  (kirkland) wrote :

Michal-

How do you propose that we solve this problem?

:-Dustin

Tyler Hicks (tyhicks) wrote :

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?

Changed in ecryptfs:
assignee: Michal Hlavinka (mhlavink) → Tyler Hicks (tyhicks)
Michal Hlavinka (mhlavink) wrote :

> 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.

Felix Lechner (felix.lechner) wrote :

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]

Tuomas Heino (iheino+ub) wrote :

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) wrote :

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

Changed in ecryptfs:
status: Confirmed → Incomplete
status: Incomplete → Won't Fix
Dustin Kirkland  (kirkland) wrote :

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!

Changed in ecryptfs:
assignee: Tyler Hicks (tyhicks) → nobody
Dustin Kirkland  (kirkland) wrote :

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

Michal Hlavinka (mhlavink) wrote :

$ 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

Tyler Hicks (tyhicks) on 2011-12-14
Changed in ecryptfs:
status: Won't Fix → Confirmed
importance: High → Low
insaner (insaner) wrote :

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) wrote :

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

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.