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

[Michael Loftis]

--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.

Is there any plans at all to fix this bug?  This breaks stuff for us even 
completely ignoring the use of any jails as relative symlinks will 
misbehave under Linux.