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

[Michael Loftis]

--On November 15, 2007 1:27:29 PM -0700 Michael Loftis <mloftis@wgops.com> 
wrote:

>
>
> --On November 8, 2007 4:54:03 PM -0700 Michael Loftis <mloftis@wgops.com>
> wrote:
>
>>
>>
>> --On November 8, 2007 3:46:16 PM -0800 Russ Allbery <rra@stanford.edu>
>> wrote:
>>
>>> Jim Rees <rees@umich.edu> writes:
>>> <...>
>>>> 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.
>>>
>>> The issue is with multiple paths to the same directory, which doesn't
>>> require a loop.
>>
>> Precisely.  See my other response about using my findings in conjunction
>> with yours to maybe crawl out of a chroot....not entirely sure.  Jeffrey
>> Altman replied with some chroot related information but I haven't had a
>> chance to look at it yet.
>>>
>>> Does the same problem happen with bind mounts?  And if not, can we use
>>> whatever solution was used for bind mounts to fix this problem?
>>
>> It doesn't.  Bind mounts work quite differently.  Inside the kernel it
>> recognizes the mount traversal, something AFS isn't causing right now.
>> The kernel "sees" the mount targets, even though they end up pointing to
>> the same filesystem structures as the source of the bind mount.
>
> Yeah I've confirmed this really does break symlink traversal in ALL cases
> if it goes across an AFS Mount.  Any random user using chdir() (not bash
> cd) will end up in the first place a mount was stat-ed from but *only* in
> the Linux implementation of OpenAFS clients.

I should clarify, whenever referencing the parent directory of a mount. 
bash emulates cd's in a funky way using an internal representation of the 
path (this makes it more comfortable for users) other shells do other 
things.