Increase recursive symlink limit from 5 to 8

The comment in do_follow_link() do not match the code. The comment explain that the limit for recursive symlinks are 8, but the code limit it to 5. This is the current comment:

/*
* This limits recursive symlink follows to 8, while
* limiting consecutive symlinks to 40.
*
* Without that kind of total limit, nasty chains of consecutive
* symlinks can cause almost arbitrarily long lookups. */

I discovered it when I ran into a problem with the following symlinks producing the error message "Too many levels of symbolic links" when I tried to run /usr/lib/sendmail in our current software configuration.

/usr/lib/sendmail -> /local/sbin/sendmail
/local/sbin/sendmail -> /store/store/diskless/.exim/ver-4.22/sbin/sendmail
/store/store/diskless/.exim/ver-4.22/sbin/sendmail -> /local/sbin/exim /local/sbin/exim ->

    /store/store/diskless/.exim/ver-4.22/sbin/exim@386linuxlibc62

As you can see, this have to visit exactly 5 files to reach the real file "/store/store/diskless/.exim/ver-4.22/sbin/exim@386linuxlibc62".

I discovered this when testing Debian for the first time using this software configuration. RedHat did not have any problems follwing the links, which suggests to me that they already increased the limit.

The fix seem to be to bring the code in sync with the comment of the function, and increase the limit from 5 to 8.

@@ -335,7 +335,7 @@
 static inline int do_follow_link(struct dentry *dentry, struct nameidata *nd)
 {
        int err;
-       if (current->link_count >= 5)
+       if (current->link_count >= 8)
                goto loop;
        if (current->total_link_count >= 40)
                goto loop;

(I'm not on this mailing list, and do not really know how to proceed to increase the chances of this patch being accepted into the official source. Please CC me if you reply. :)

[Petter Reinholdtsen]

Hm, I wrote the following test script to test the current limit on different unixes, and was surprised by the differences. And, my previous claim that RedHat must have increased this limit was wrong. The test on RedHat showed that it had the same limit as Debian. Not sure why the symlinks in question seemed to be working on RedHat.

  Linux:         Symlink limit seem to be 6 path entities.
  AIX:           Symlink limit seem to be 21 path entities.
  HP-UX:         Symlink limit seem to be 21 path entities.
  Solaris:       Symlink limit seem to be 21 path entities.
  Irix:          Symlink limit seem to be 31 path entities.
  Mac OS X:      Symlink limit seem to be 33 path entities.
  Tru64 Unix:    Symlink limit seem to be 65 path entities.

I really think this limit should be increased in Linux. Not sure how high it should go, but from 5 to somewhere between 20 and 64 seem like a good idea to me.

Petri Koistinen suggested that I sent my patch to <URL:http://www.kernel.org/pub/linux/kernel/people/rusty/trivial/>. I'll do that, replacing 5 with 64 instead of 8. No need to have any lower limit than Tru64 Unix, I figure.

This is the test program I used:

#!/bin/sh
#
# Author: Petter Reinholdtsen
# Date: 2004-01-11
#
# Script to detect the kernels "recursive" symlink limit. This seem

# to differ from Unix to Unix, and from version to version.

TMPDIR=test

error() {
    echo $1
    exit 1
}

mkdir $TMPDIR || error "Unable to create $TMPDIR/"
(
cd $TMPDIR
for limit in seq 1 10; do
last=foo
echo "Limit $limit" > foo
for n in seq $limit ; do
ln -s $last $n
last="$n"
done
cat $last > /dev/null 2>&1 || error "Symlink limit seem to be $limit path entities." for n in seq $limit ; do
rm $n
done
done
)
rm -rf $TMPDIR

6 does seem pretty low. What was the reason for setting it there? Is there a downside to increasing it?

|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
|              Ashes to ashes, dust to dust.               |
|      The proof of the pudding, is under the crust.       |
|------------------------------<[email protected]>---|

Search the archives for "symlink recursion":

http://marc.theaimsgroup.com/?l=linux-kernel&w=2&r=1&s=symlink+recursion&q=b

Peter Osterlund - [email protected]
http://w1.894.telia.com/~u89404340

It was reduced down from 8 because it can lead to stack overflows. Recursive links like this usually point at a quite broken filesystem setup too afaik.

At Sun, 11 Jan 2004 10:49:30 +0100,

But I still think 6 is too small from user level point of view, as Petter wrote. The example is /usr/lib library links. I got bug report which complained that a library want to use "bounce" link:

	/usr/lib/liba -> /etc/alternatives/liba -> /usr/lib/another/libb.

If .so file uses major.minor scheme, then /usr/lib/liba.so links:

	/usr/lib/liba.so -> /usr/lib/liba.so.2 -> /usr/lib/liba.so.2.3

and so on. It can easily exceed 6 symlinks. I think the correct fix is to make VFS not to overflow stacks. Is it allowable change?

Regards,
-- gotom

One of the reasons for the limit is that it doesn't require any special detection of circular links.

Måns Rullgård
[email protected]

You are quite welcome to submit clean patches that would do that.
So far all suggested "solutions" had turned out to be broken _and_ ugly.

Ugly, possibly - broken, no.

When I first saw this thread I thought "yeah, that's a low limit", but now I'm not so sure.

The truth is, up until a few days ago when this thread started, I wasn't even aware that there was a limit.[1] Which means, that for me at least, I have never had the need to exceed the limit. Because, if I had I would have discovered what that limit was.

I'm not an "occasional dual-booting" Linux user, I've been using Linux _exclusively_ since late 1996. In that 7, going on 8 years I have _never_ hit the limit. Does that mean that it is high enough? For me, yes. For others, I can't say.

Footnotes:
[1] Not quite true, I knew that there probably was some sort of limit, I just didn't know what it was.

|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
|              Ashes to ashes, dust to dust.               |
|      The proof of the pudding, is under the crust.       |
|------------------------------<[email protected]>---|

I think we cannot set this value much higher due to constraints in kernel stack size, and this limits maximum recursion levels.