Re: symlinks.

Linus Torvalds (torvalds@transmeta.com)
Tue, 14 Apr 1998 09:38:59 -0700 (PDT)

On Tue, 14 Apr 1998, C. Scott Ananian wrote:
>
> > It's also seems odd (IMHO) that the comments claim the link-following
> > is iterative, but the link-limit is enforced in follow_link (which
> > appears to have been done with the old recursive scheme in mind.) It
> > seems to me the "for(;;)" in lookup_dentry() should be replaced with a
> > link-limiting loop instead.
>
> I think the code was *half* fixed. I don't know what the code used to
> look like, but my guess is that lookup_dentry used to invoke *itself*
> directly to handle embedded symlinks in paths. i.e. a/b/c where b was a
> symlink would fetch b and then recurse to handle b/c. I think you'd have
> to do some old-kernel surfing to know for sure. Or we could just ask
> Linus. ;-)

The code that the comment refers to never actually worked correctly. It
did all the symlink traversals completely in the VFS layer, and the
"follow_link" function was actually never used (it used "readlink()" and
trversed the link in the VFS layer). It had various problems:

- not all "follow_link" functions do the same as a lookup of the path
returned by readlink. Normal filesystems do this, but it is broken for
virtual filesystems like /proc, who want to do something more
interesting for follow-link.
- it didn't get the nesting right, if I remember correctly.

Anyway, you can look into the earliest dcache-kernels (2.1.60? something
around that timeframe), to look. Or maybe one of the pre-kernels, I may
actually have edited this in between "real" releases.

> The 'for (;;)' in lookup_dentry is handling the individual components of
> the path. It has very little to do with symlinks.

Right.

> > > We could then use Tarjan's algorithm to accurately detect loops without
> > > false-positives.
> >
> > That's the one with the "chaser" that advances once for every two
> > advances of the "real", right? (detects loop within 2n?)
>
> Right. I'm running this on my machine as I write this. As soon as diff
> is finished, I'll mail out the patch.

Note that this doesn't work either. The reason? Kernel memory usage and
latency. You still have to limit the recursion _somewhere_, so it is not
strictly needed to even try to do a perfect loop detector (the "somewhere"
ha dprobably be less than a hundred iterations or so).

> > It also would (I think) bring the code into alignment with the
> > documentation, although we all know the proverb about when the code
> > and docs disagree ;-)
>
> I agree. The patch is very short: do_follow_link() is the only major
> function changed, apart from the 1->0 argument changes in
> <fs>_follow_link. Linus, if you want to wait until 2.3.X for this, I
> understand. The real motivation for the patch was the report that
> the standard 'bind' distribution wouldn't compile on linux because of the
> way the symlinks were nested.

I'd like to see the patch, but I strongly suspect that I'd prefer to wait
until 2.3 to apply it.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu