Re: PATCH: smart symlink loop detection.

Linus Torvalds (torvalds@transmeta.com)
20 Apr 1998 19:25:28 GMT


In article <Pine.GSO.3.96.980420113705.27291B-100000@csb>,
Adam D. Bradley <artdodge@cs.bu.edu> wrote:
>
>I took a look at how FreeBSD does it... apparently, when in their
>equivalent of lookup_dentry(), when they discover a symlink component
>in the pathname they overwrite it in-place with the symlink's "value",
>then re-start the resolution process using the new name (w/o changing
>"base"). If expanding a symlink would cause the buffer to overflow,
>they return -ENAMETOOLONG. Simple, graceful, makes sense, and allows
>"max-symlinks" to be implemented as a simple, flat counter/countdown.

And means that you can't handle the name in-line, nor that you can allow
the low-level filesystem to have its own "follow_link()".

In addition, it puts a rather bad length-restriction on symlinks.

Quite frankly, I'd ratehr have a _reliable_ nesting level counter like
Linux already has rather than the above thing. Especially the name
length thing makes the above extremely unpredictable: some symlinks work
fine, while others fail. In fact, the _same_ symlink can work or fail
depending on where you happen to be using it - even with no nesting at
all.

In short, I think the FreeBSD solution is a _lot_ worse than the Linux
one.

Linus

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