ecryptfs-users team mailing list archive

[Alberto Bertogli <albertito@xxxxxxxxxxxxxx>]

Hi!

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.

Thanks a lot,
		Alberto


PS (just in case it's not the usual procedure): please CC me on replies, as
I'm not subscribed to the list.