SYMLOOP_MAX

[Roland McGrath <roland at hack dot frob dot com>]

In my decrufting activities I notice code using the old BSD
<sys/param.h> name MAXSYMLINKS.  On the roland/symloop_max branch I've
changed this to use the proper POSIX method of looking for SYMLOOP_MAX
and possibly using sysconf to get it.

But I've noticed that for Linux configurations this actually changes
the code.  We have MAXSYMLINKS defined to 20 in sys/param.h, but
SYMLOOP_MAX defined nowhere (and so sysconf won't claim any limit for
it either).

Looking at the kernel source, it doesn't have a single coherent
constant that it uses internally at all.  In a few places, it
hard-codes a limit of 40.  In another place, it uses 8 (symbolically
MAX_NESTED_LINKS).  Rather than having a single straightforward limit,
it applies different limits to the number of immediate symlinks to
symlinks it will follow ("recursive symlink follows", limited to 8)
and the total number of symlinks it will follow in whole file name
resolution ("consecutive symlinks", limited to 40).  The traditional
rule from 4.2BSD (the inventor of symlinks) was a simple maximum of 8
symlink crossings in a file name resolution.

POSIX specifies {SYMLOOP_MAX} as, "Maximum number of symbolic links
that can be reliably traversed in the resolution of a pathname in the
absence of a loop."  The minimum allowed value for that, called
{_POSIX_SYMLOOP_MAX}, is 8.  As I read that, it means we need to use 8
here, since there is a straightforward scenario in which the kernel
will fail with ELOOP when faced with a chain of 9 symlinks.

What do people think?  

Should we start defining SYMLOOP_MAX for Linux configurations?  

Should we instead only make sysconf return a value for it, so that the
value POSIX-conformant programs use can be changed later with a shared
library update and not require recompiling applications?

Should we change MAXSYMLINKS to match SYMLOOP_MAX?

My take on it is that the old BSD name MAXSYMLINKS was always meant to
have the same semantics as what POSIX enshrined as SYMLOOP_MAX, so
<sys/param.h> should just have
	#define MAXSYMLINKS SYMLOOP_MAX
and that we ought to define SYMLOOP_MAX to 8.

The practical effect of this inside the library (or that plus my
roland/symloop_max change) is that chroot_canon (private routine in
ldconfig) and canonicalize_file_name/realpath will diagnose ELOOP at
chains of 8 symlinks instead of chains of 20.  Depending on the kind
of symlink arrangement it is, this is either a longer chain (larger
number of immediate symlinks to symlinks) or a shorter chain (smaller
number of total symlinks in the file name resolution) than what the
kernel will allow before diagnosing ELOOP.  The practical effect for
programs that use MAXSYMLINKS, conditionally use SYMLOOP_MAX, or call
sysconf (_SC_SYMLOOP_MAX) is not exactly known.


Thanks,
Roland