Quoting Dustin Kirkland ([email protected]): > On Fri, Nov 6, 2009 at 4:07 PM, Alberto Bertogli > <[email protected]> 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 _______________________________________________ Mailing list: https://launchpad.net/~ecryptfs-users Post to : [email protected] Unsubscribe : https://launchpad.net/~ecryptfs-users More help : https://help.launchpad.net/ListHelp
