[OpenAFS-devel] getcwd() on Linux 2.6.18+OpenAFS 1.4.2 bugs/errors.

[Michael Loftis]

--On November 8, 2007 6:40:42 PM -0500 Jim Rees <rees@umich.edu> wrote:

> Michael Loftis wrote:
>
>   No.  The problem is pwd (getcwd()) returns erroneous information.
>
> You said /afs/mw/u/m/mloftis/var and /afs/modwest.com/u/j/jslife/var were
> the same thing.  So if you cd to one, it's perfectly normal to "pwd" and
> get the other path.
>
>   when you chroot it returns paths *outside* the chroot.
>
> It's not outside the chroot.  You've created a path that leads from the
> chroot back to what you call the outside.  This is the behavior I expect.

It is so outside the chroot.  The jail does not have any system mounts at 
all (/afs, /proc, etc).  pwd (getcwd()) sholdn't be returning information 
outside the current context of root if the filesystem is behaving itself.

The reply to Russ' bug report indicates the OpenBSD port has the correct 
semantics, my simple test case on Darwin which as I understand it was based 
on the AFS BSD port doesn't display this weird behavior of returning 
differing paths.  I can't test chroot-ing since I don't have an environment 
for that.

>
> It sounds like what you want is for the kernel to keep track not only of
> the files and directories you have open, but the paths by which you got
> to them. Not impossible, but I think it would require changes to the
> kernel outside afs.  And it would change the semantics of the file system.
>
> I'll admit that what you've seen can be surprising.  That's why most file
> systems prohibit loops.  It would be nice if afs could do this but it
> would be hard to implement.  And if we did, you would lose your /afs/mw
> shortcut.


I'm also going to try to test Russ' report, and see if I can replicate that 
and use it to crawl out of a chroot() environment.  That has wider 
implications than just "looks funny".


--
"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler