ecryptfs-mount-private fails the first time after boot

ecryptfs-mount-private fails the first time after boot

[Benjamin Moody]

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

Re: ecryptfs-mount-private fails the first time after boot

[Tyler Hicks]

[-- Attachment #1: Type: text/plain, Size: 2947 bytes --]

On 2013-11-15 17:51:49, Benjamin Moody wrote:
> 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.

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

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

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

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.

> 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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: ecryptfs-mount-private fails the first time after boot

[Benjamin Moody]

Thanks for your quick reply!

On 11/15/13, Tyler Hicks <tyhicks@canonical.com> wrote:
> On 2013-11-15 17:51:49, Benjamin Moody wrote:
>> 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?

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

> 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

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

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

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

Re: ecryptfs-mount-private fails the first time after boot

[Tyler Hicks]

[-- Attachment #1: Type: text/plain, Size: 4711 bytes --]

On 2013-11-15 19:29:01, Benjamin Moody wrote:
> Thanks for your quick reply!
> 
> On 11/15/13, Tyler Hicks <tyhicks@canonical.com> wrote:
> > On 2013-11-15 17:51:49, Benjamin Moody wrote:
> >> 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?
> 
> >> 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-
> >> ...
> >
> > 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
> 
> > 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
> 
> 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.)
> 
> >> 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.
> >
> > 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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: ecryptfs-mount-private fails the first time after boot

[Benjamin Moody]

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