All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tyler Hicks <tyhicks@canonical.com>
To: Benjamin Moody <benjamin.moody@gmail.com>
Cc: ecryptfs@vger.kernel.org
Subject: Re: ecryptfs-mount-private fails the first time after boot
Date: Fri, 15 Nov 2013 15:34:46 -0800	[thread overview]
Message-ID: <20131115233445.GA4911@boyd> (raw)
In-Reply-To: <CAAk6P0VYWJA+pC6CfeLKhZc6kZ5EVASS+8ELoAUEWCOnqVhhuw@mail.gmail.com>

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

  reply	other threads:[~2013-11-15 23:34 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-15 22:51 ecryptfs-mount-private fails the first time after boot Benjamin Moody
2013-11-15 23:34 ` Tyler Hicks [this message]
2013-11-16  0:29   ` Benjamin Moody
2013-11-16  0:41     ` Tyler Hicks
2013-11-16  1:00       ` Benjamin Moody

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131115233445.GA4911@boyd \
    --to=tyhicks@canonical.com \
    --cc=benjamin.moody@gmail.com \
    --cc=ecryptfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.