ecryptfs-users team mailing list archive

[John Johansen <john.johansen@xxxxxxxxxxxxx>]

On 02/14/2011 09:23 AM, Dustin Kirkland wrote:
> On Fri, Nov 6, 2009 at 4:07 PM, Alberto Bertogli
> <albertito@xxxxxxxxxxxxxx> wrote:
>> A friend is having a very strange bug, that I think (I'm not sure) it might be
>> ecryptfs related. She has Ubuntu 9.10 (installed 9.04, then upgraded) and uses
>> ecryptfs to encrypt her home directory (using the standard Ubuntu setup).
>>
>> Sometimes (no idea when or why) the following happens: using GNU screen, you
>> open a new shell (ctrl-a c) bash prompt says it's in '/'; pwd says it's in
>> '/'.
>>
>> ls shows the contents of her home directory. You can do cat <file in her home
>> directory> and it works doing cat <file in /> does not work.
>>
>> I've done a couple of straces and the behaviour is consistant with the current
>> directory being her home, but getcwd() returning '/'.  I verified this also
>> using Python's os module, just in case it was a tool issue.
>>
>> I can also cd <dir inside her home> and pwd shows '/<dir inside her home>',
>> with the same behaviour as before. While I'm in there, I get the same
>> behaviour as before (cat works, open works, etc., but getcwd() returns the
>> wrong directory). However, if I do 'cd /<dir in her home>' I get ENOENT.
>>
>> The problem goes away if I do 'cd' or 'cd /<her home dir>'
>>
>> >From what I can see, it looks like getcwd() is using '/' instead of $HOME.
>>
>>
>> At the moment I can reproduce this at will by creating new shells inside an
>> existing screen. It does not happen in new terminals. She said this has
>> happened before, but has no idea when or why (although it happened also in
>> 9.04). I'm not sure if after she reboots or closes this screen it will be so
>> easy to reproduce (it looks like the shells are inheriting this behaviour from
>> the screen process).
>>
>>
>> If you need any further information (or want me to test anything), please let
>> me know.
> 
> Hi Alberto,
> 
> First, my apologies for taking so long to respond.  Your note (along
> with a couple of others) got lost, having been picked up by
> Launchpad's filtering.
> 
> In any case, I have actually seen this maybe 3 times in the last few
> years.  It is a strange bug, indeed.  Each time it happened, I had
> very recently (within that screen session) done an apt-get
> dist-upgrade.  I think it's somehow related to that -- possibly the
> changeover to a new libc library or something.
> 
> If you're still seeing this, please open a bug at
> http://bugs.launchpad.net/ecryptfs, and please provide as *much*
> information as possible about how to reproduce the error.
> 
This behavior would be consistent with a lazy unmount of the ecrypted home directory.
Since the process retrains a dentry, mount reference to the encrypted home everything
is still available but getcwd fails out with / as it can't walk past the encrypted
home mount point.

So if this is the cause its really 2 bugs, the way the kernel returns path for lazily
unmounted directories, which isn't going to change for various reasons, and how the
shell is dealing with the lazy unmount and remount of the encrypted home.  The solution
of course is to cd to an absolute path, using cd to directories within the old mount
tree won't fix the problem.