--On November 15, 2007 1:27:29 PM -0700 Michael Loftis <[EMAIL PROTECTED]>
wrote:
--On November 8, 2007 4:54:03 PM -0700 Michael Loftis <[EMAIL PROTECTED]>
wrote:
--On November 8, 2007 3:46:16 PM -0800 Russ Allbery <[EMAIL PROTECTED]>
wrote:
Jim Rees <[EMAIL PROTECTED]> 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.
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
