ecryptfs-users team mailing list archive

["Serge E. Hallyn" <serge.hallyn@xxxxxxxxxxxxx>]

Quoting Dustin Kirkland (kirkland@xxxxxxxxxx):
> 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.
> 
> Thanks!

It sounds to me like pam_ecryptfs lazily unmounted and then remounted her
home directory.  So long as you're inside her homedir, you can move around
in there with relative pathnames.  'cd /subdir' won't work bc the report
by getcwd of '/' doesn't really mean '/', but '(disconnected)/'.  If
'cd /home-subdir' worked, that would be a kernel bug.

If I had to guess at how to reproduce, I'd say:  log in through X, start
a screen session, disconnect that, log out of X, then log back into X
and reconnect to screen.  But hopefully that does *not* reproduce it and,
as Dustin speculated, an apt-get update of pam somehow confused the
mount tally and caused premature (lazy) umount.

-serge