Haven't managed to find anything in ecryptfs-utils relating to this.
Furthermore, I discovered this issue doesn't effect other terminal
multiplexers such as tmux so possibly thinking this is specific to gnu
screen.
On Wed, Aug 25, 2010 at 18:02, Serge Hallyn <email address hidden>wrote:
> Quoting Russell Davies (<email address hidden><russell%<email address hidden>>
> ):
> > So this is a bug with screen?
>
> No, it has to do with however ecryptfs-utils and pam are
> doing the homedir automount. TBH I'm not even sure it's
> as clever as I was thinking it was (bc I can't find it
> in the code).
>
> --
> Strange getcwd() behaviour
> https://bugs.launchpad.net/bugs/479248
> You received this bug notification because you are a direct subscriber
> of a duplicate bug (622858).
>
> Status in eCryptfs - Enterprise Cryptographic Filesystem: Incomplete
>
> Bug description:
> 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
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/ecryptfs/+bug/479248/+subscribe
>
Haven't managed to find anything in ecryptfs-utils relating to this.
Furthermore, I discovered this issue doesn't effect other terminal
multiplexers such as tmux so possibly thinking this is specific to gnu
screen.
On Wed, Aug 25, 2010 at 18:02, Serge Hallyn <email address hidden>wrote:
> Quoting Russell Davies (<email address hidden> <russell% <email address hidden>> /bugs.launchpad .net/bugs/ 479248 /bugs.launchpad .net/ecryptfs/ +bug/479248/ +subscribe
> ):
> > So this is a bug with screen?
>
> No, it has to do with however ecryptfs-utils and pam are
> doing the homedir automount. TBH I'm not even sure it's
> as clever as I was thinking it was (bc I can't find it
> in the code).
>
> --
> Strange getcwd() behaviour
> https:/
> You received this bug notification because you are a direct subscriber
> of a duplicate bug (622858).
>
> Status in eCryptfs - Enterprise Cryptographic Filesystem: Incomplete
>
> Bug description:
> 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
>
> To unsubscribe from this bug, go to:
> https:/
>