ecryptfs-mount-private fails the first time after boot

Discussion:

Benjamin Moody

2013-11-15 22:51:49 UTC

I don't know if this list is the right place to be asking this
question; please let me know if there's a better place. I'm not
subscribed to the list so please CC me on replies.

I'm using ecryptfs on Scientific Linux 6.4 (kernel
2.6.32-358.23.2.el6.x86_64, ecryptfs-utils 82-6.el6_1.3) and I'm
having a minor but annoying problem. The first time I run
'ecryptfs-mount-private' after booting the system, it always fails.
(It's happened at least 10 times; I'm quite certain that I'm entering
the passphrase correctly.) I then need to run
'ecryptfs-umount-private' and 'ecryptfs-mount-private' again in order
for my files to finally show up.

I believe I selected all the default options when I set the filesystem
up, except that I had it use a separate passphrase, not my login
password. It's encrypted with AES and filename encryption is enabled.
It's mounted at /home/benjamin/Private/ and the encrypted files are
stored in /home/benjamin/.Private/.

When I run ecryptfs-mount-private for the first time, it shows the following:

$ ecryptfs-mount-private
Enter your wrapping passphrase:
Inserted auth tok with sig [...] into the user session keyring
keyctl_search: Required key not available
Perhaps try the interactive 'ecryptfs-mount-private'

At this point, the following messages appear in dmesg:

$ dmesg
...
TECH PREVIEW: ecryptfs may not be fully supported.
Please review provided documentation for limitations.
SELinux: initialized (dev ecryptfs, type ecryptfs), uses genfs_contexts

And at this point, the filesystem is *mounted* but the files are not
correctly decrypted (i.e. Private appears to be an exact mirror of
.Private):

$ ls Private/
ECRYPTFS_FNEK_ENCRYPTED.FWaO.4n6KQUoiUR2FAbPNmeUAR1Zw4f3.rLCHzv3PNoOtExPXP.Ei0KiAE--
ECRYPTFS_FNEK_ENCRYPTED.FXaO.4n6KQUoiUR2FAbPNmeUAR1Zw4f3.rLC-NRvX4ESyXeGh90V8z6JRo2qp.xjwPLn8Fz1BXP8u22-
...

I then unmount and remount it:

$ ecryptfs-umount-private
keyctl_search: Required key not available
Perhaps try the interactive 'ecryptfs-mount-private'

$ ecryptfs-mount-private
Enter your wrapping passphrase:
Inserted auth tok with sig [...] into the user session keyring

at which point it works as expected. If I later run
ecryptfs-umount-private again, it doesn't display the 'keyctl_search'
error message.

So, does anyone know why this might be happening? Is it a known bug
in the kernel and/or ecryptfs-utils? If it's not easy to fix, is
there a workaround?

Thanks in advance,
Benjamin Moody

Tyler Hicks

2013-11-15 23:34:46 UTC

Permalink

Post by Benjamin Moody
I'm using ecryptfs on Scientific Linux 6.4 (kernel
2.6.32-358.23.2.el6.x86_64, ecryptfs-utils 82-6.el6_1.3)

I don't have a system derived from RHEL 6 to test from. But I gave it a
shot with Ubuntu 10.04 (kernel 2.6.32-52.114-generic, ecryptfs-utils
83-0ubuntu3.2.10.04.3).

I wasn't able to reproduce the bug that you're seeing. I thought that
maybe the RHEL 6 derivatives don't enable the pam_ecryptfs module and
that it does something that ecryptfs-mount-private needs, so I commented
it out of my pam configs and tried again but still couldn't reproduce
it.

Post by Benjamin Moody
$ ecryptfs-mount-private
Inserted auth tok with sig [...] into the user session keyring
keyctl_search: Required key not available
Perhaps try the interactive 'ecryptfs-mount-private'
$ dmesg
...
TECH PREVIEW: ecryptfs may not be fully supported.
Please review provided documentation for limitations.
SELinux: initialized (dev ecryptfs, type ecryptfs), uses genfs_contexts
And at this point, the filesystem is *mounted* but the files are not
correctly decrypted (i.e. Private appears to be an exact mirror of
$ ls Private/
ECRYPTFS_FNEK_ENCRYPTED.FWaO.4n6KQUoiUR2FAbPNmeUAR1Zw4f3.rLCHzv3PNoOtExPXP.Ei0KiAE--
ECRYPTFS_FNEK_ENCRYPTED.FXaO.4n6KQUoiUR2FAbPNmeUAR1Zw4f3.rLC-NRvX4ESyXeGh90V8z6JRo2qp.xjwPLn8Fz1BXP8u22-
...

It would be nice to see the mount options, from /proc/mounts, at this
point.

I'm having to make some assumptions, but it looks like the mount happens
without the filename encryption key being loaded into the kernel
keyring.

Also, seeing how many user keys are loaded at this point would be
helpful:

$ keyctl show | grep user: | wc -l
2

Post by Benjamin Moody
$ ecryptfs-umount-private
keyctl_search: Required key not available
Perhaps try the interactive 'ecryptfs-mount-private'
$ ecryptfs-mount-private
Inserted auth tok with sig [...] into the user session keyring
at which point it works as expected.

At this point, the keyctl show command above should spit out the same
result as above. But, I think you'll see "1" printed when you run it
above, and "2" printed now.

Post by Benjamin Moody
So, does anyone know why this might be happening?

No. I don't recall a fixed bug similar to this, but you should search
our bug tracker (https://bugs.launchpad.net/ecryptfs). Also, take a look
through the RHEL bug tracker.

Sorry I'm not more help at this point but I can't reproduce it at the
moment and don't recall us fixing anything like this. Dustin tends to
this portion of ecryptfs-utils, so maybe he'll remember something when
he sees your email.

Tyler

Benjamin Moody

2013-11-16 00:29:01 UTC

Permalink

Thanks for your quick reply!

Post by Tyler Hicks

Post by Benjamin Moody
I'm using ecryptfs on Scientific Linux 6.4 (kernel
2.6.32-358.23.2.el6.x86_64, ecryptfs-utils 82-6.el6_1.3)

I don't have a system derived from RHEL 6 to test from. But I gave it a
shot with Ubuntu 10.04 (kernel 2.6.32-52.114-generic, ecryptfs-utils
83-0ubuntu3.2.10.04.3).
I wasn't able to reproduce the bug that you're seeing. I thought that
maybe the RHEL 6 derivatives don't enable the pam_ecryptfs module and
that it does something that ecryptfs-mount-private needs, so I commented
it out of my pam configs and tried again but still couldn't reproduce
it.

I'm pretty sure it isn't using pam_ecryptfs, but that shouldn't make a
difference in this case (since I'm not using the login password),
right?

Post by Tyler Hicks

It would be nice to see the mount options, from /proc/mounts, at this
point.

/home/benjamin/.Private /home/benjamin/Private ecryptfs
rw,relatime,ecryptfs_sig=dceda47e1c1e65a1,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs
0 0

Post by Tyler Hicks
I'm having to make some assumptions, but it looks like the mount happens
without the filename encryption key being loaded into the kernel
keyring.
Also, seeing how many user keys are loaded at this point would be
$ keyctl show | grep user: | wc -l
2

Interesting. It shows 0 when first starting up, and 1 after I run
ecryptfs-mount-private for the first time. Looks like you're right
and it's loading the *file* decryption key but not the *filename* key.
(In fact I was partially incorrect before; the file contents are
being decrypted correctly, it's just the filenames that remain
encrypted.)

Post by Tyler Hicks

At this point, the keyctl show command above should spit out the same
result as above. But, I think you'll see "1" printed when you run it
above, and "2" printed now.

Indeed, it now shows 2, and /proc/mounts shows

/home/benjamin/.Private /home/benjamin/Private ecryptfs
rw,relatime,ecryptfs_fnek_sig=9a046cc859c834ba,ecryptfs_sig=dceda47e1c1e65a1,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs
0 0

Post by Tyler Hicks

Post by Benjamin Moody
So, does anyone know why this might be happening?

No. I don't recall a fixed bug similar to this, but you should search
our bug tracker (https://bugs.launchpad.net/ecryptfs). Also, take a look
through the RHEL bug tracker.

Thanks. I'll do so.

Benjamin

Tyler Hicks

2013-11-16 00:41:35 UTC

Permalink

Post by Benjamin Moody
Thanks for your quick reply!

Post by Tyler Hicks

Post by Benjamin Moody
I'm using ecryptfs on Scientific Linux 6.4 (kernel
2.6.32-358.23.2.el6.x86_64, ecryptfs-utils 82-6.el6_1.3)

I don't have a system derived from RHEL 6 to test from. But I gave it a
shot with Ubuntu 10.04 (kernel 2.6.32-52.114-generic, ecryptfs-utils
83-0ubuntu3.2.10.04.3).
I wasn't able to reproduce the bug that you're seeing. I thought that
maybe the RHEL 6 derivatives don't enable the pam_ecryptfs module and
that it does something that ecryptfs-mount-private needs, so I commented
it out of my pam configs and tried again but still couldn't reproduce
it.

I'm pretty sure it isn't using pam_ecryptfs, but that shouldn't make a
difference in this case (since I'm not using the login password),
right?

Post by Tyler Hicks

It would be nice to see the mount options, from /proc/mounts, at this
point.

/home/benjamin/.Private /home/benjamin/Private ecryptfs
rw,relatime,ecryptfs_sig=dceda47e1c1e65a1,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs
0 0

Post by Tyler Hicks

At this point, the keyctl show command above should spit out the same
result as above. But, I think you'll see "1" printed when you run it
above, and "2" printed now.

Indeed, it now shows 2, and /proc/mounts shows
/home/benjamin/.Private /home/benjamin/Private ecryptfs
rw,relatime,ecryptfs_fnek_sig=9a046cc859c834ba,ecryptfs_sig=dceda47e1c1e65a1,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs
0 0

Now that I know my assumptions were correct, I think I know the cause of
the problem. When the eCryptfs kernel module is loaded, it creates
/sys/fs/ecryptfs/version to let userspace (ecryptfs-utils) know what
features the eCryptfs kernel module supports. One of those features is
filename encryption...

Ubuntu builds the eCryptfs module into the kernel, so that file always
exists. I bet RHEL, and its derivatives, do not build it in. So, the
file in sysfs does not exist and the utilities can't tell if the kernel
supports filename encryption. The first mount happens without the
filename encryption key and the eCryptfs kernel module is auto-loaded
when doing the mount. Now, the sysfs file exists and future mounts
result in filename encryption being enabled.

Try `modprobe ecryptfs` before running ecryptfs-mount-private for the
first time and see if the filenames are decrypted.

Tyler

Benjamin Moody

2013-11-16 01:00:14 UTC

Permalink

Running modprobe ecryptfs was all I needed. I guess this is something
that should really be fixed at the package level, but now that I know
what's going on I can easily kludge around it. :)

(Although, I don't know if this makes sense, but wouldn't it be better
in a situation like this to *try* to load both keys, even if we don't
know the kernel supports filename encryption, and only fall back to
showing the encrypted filenames if that fails?)

Thanks again!

Benjamin