--On November 8, 2007 6:40:42 PM -0500 Jim Rees <[EMAIL PROTECTED]> 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 _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
