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.
--- linux-2.4.24/fs/namei.c.orig Wed Jan 7 23:46:03 2004
+++ linux-2.4.24/fs/namei.c Wed Jan 7 23:46:34 2004
@@ -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]
> 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:
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
Steve Youngs <[email protected]> writes:
> * Petter Reinholdtsen <[email protected]> writes:
>
> > 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.
>
> 6 does seem pretty low. What was the reason for setting it there? Is
> there a downside to increasing it?
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
> 6 does seem pretty low. What was the reason for setting it there? Is
> there a downside to increasing it?
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.
On Sun, 2004-01-11 at 08:01, Steve Youngs wrote:
> * Petter Reinholdtsen <[email protected]> writes:
>
> > 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.
>
> 6 does seem pretty low. What was the reason for setting it there? Is
> there a downside to increasing it?
I think we cannot set this value much higher due to constraints in
kernel stack size, and this limits maximum recursion levels.
At Sun, 11 Jan 2004 10:49:30 +0100,
Arjan van de Ven wrote:
> > 6 does seem pretty low. What was the reason for setting it there? Is
> > there a downside to increasing it?
>
> 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.
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
GOTO Masanori <[email protected]> writes:
> At Sun, 11 Jan 2004 10:49:30 +0100,
> Arjan van de Ven wrote:
>> > 6 does seem pretty low. What was the reason for setting it there? Is
>> > there a downside to increasing it?
>>
>> 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.
>
> 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?
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]
On Fri, Jan 16, 2004 at 09:45:47AM +0900, GOTO Masanori wrote:
> 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?
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.
On Fri, Jan 16, 2004 at 01:25:11AM +0000, [email protected] wrote:
> > 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?
>
> 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.