Re: MAXSYMLINKS incredibly low

[Martin Buchholz]

>>>>> "AJ" == Andreas Jaeger <[e-mail]> writes:

AJ> Hi Martin,
>>>>> Martin Buchholz writes:

>> I was shocked and dismayed when I discovered that the default value of
>> MAXSYMLINKS on my Linux system was 5, and that this is the default for
>> glibc.

AJ> Please report this to the kernel folks.  glibc just has the value that
AJ> the kernel uses.  There's nothing we can do in glibc in this case.

Hmmmm.  I guess system calls like open() have to do this as well.

However...

glibc, at least in principle, can be used on non-Linux systems, and
the kernel can be fixed separately.  I propose setting a good example
and fixing functions under the direct control of glibc, one function
at a time.  I would start with realpath().  

(I started out on this quest with the aim of stealing glibc's
realpath() for use in XEmacs.)

AJ> Check do_follow_link in linux/fs/namei.c for the 5.

There doesn't seem to be any way for the user to configure the `5', or
to ask the kernel what its value is.  I am shocked that there's not
even a #define for this 5.

Does glibc have a configure test so that its value of MAXSYMLINKS
matches the experimentally determined limit in the kernel?  What if
someone upgrades the kernel independently (very common)?  How
important is it for glibc's limit to match the kernel's limit?

The possibility of a mismatch between glibc's and the kernel's symlink
chase limit demonstrates yet again how bad it is having any kind of
arbitrary limit for this.

Why do I suddenly feel an urge to fix both the kernel *and* glibc?

Here's a new proposal:

The linux kernel and glibc are both immediately modified to raise the
symlink chase limit from 5 to a much more reasonable number.  I
recommend 128, but the limit used by SunOS and AIX, 20, is better than
doing nothing.  This is easy and safe and cheap.

Then the algorithms in both glibc and the kernel are eventually
modified to return ELOOP on true loops.

For the benefit of the linux kernel folks, I repeat the (simple)
`modified tortoise/hare' algorithm:

  Hare starts chasing symlinks as usual until you get suspicious you
  might be in a loop (say after 32 symlinks).  Then race tortoise
  against hare starting from hare's current position.  Tortoise takes
  a step every other hare step.  If tortoise and hare ever meet again,
  then you have a true symlink loop and return ELOOP.  This will never
  infloop, and also has no arbitrary limits.

I've implemented this algorithm several times for things like
following cdrs in lisp lists.

Martin