Almost sounds like a chroot environment within screen; but doing chroot requires root normally. Do any commands fail to run? "ls", "cat", etc. are all shell built-ins for most shells, so they would be able to run in a chroot. Full executables, being outside the chroot, would not. Alternatively, it's possible that ecryptfs somehow mounted over /, but then I'd expect a lot more breakage. (And the same behavior both inside and outside screen.)
Try creating another user with a similar setup and see if the same occurs. If not, it's likely she's got a setting in .screenrc, .profile, or .bash* (assuming using bash) that's doing something odd. Also, can you provide the output of "mount" by itself? This will tell us if anything is mounted on /. David On Fri, Nov 6, 2009 at 5:07 PM, Alberto Bertogli <[email protected]>wrote: > > 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. > > > _______________________________________________ > Mailing list: https://launchpad.net/~ecryptfs-users > Post to : [email protected] > Unsubscribe : https://launchpad.net/~ecryptfs-users > More help : https://help.launchpad.net/ListHelp > -- David Tomaschik, RHCE, LPIC-1 GNU/Linux System Architect GPG: 0x5DEA789B [email protected]
_______________________________________________ Mailing list: https://launchpad.net/~ecryptfs-users Post to : [email protected] Unsubscribe : https://launchpad.net/~ecryptfs-users More help : https://help.launchpad.net/ListHelp
