This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: SYMLOOP_MAX


On 7/31/2012 1:32 PM, Roland McGrath wrote:
> 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.

(1) Lowering the value of MAXSYMLINKS.

I don't like lowering MAXSYMLINKS to 8. Do we really need to do that?
Why can't we leave MAXSYMLINKS at 20, and additionally define
SYMLOOP_MAX to 8, and let the user decide which standard they want
to use?

My worry is that changing MAXSYMLINKS will break applications when
they are recompiled with a newer glibc that sets the value to 8
(even if that is more correct as a reliable maximum).

I don't want to break existing code, that would be bad. This looks
like it could break existing code.

(2) Make sysconf work.

We need sysconf working because it's the only easy way to make this
truly dynamic (unless SYMLOOP_MAX can resolve to a call to sysconf?).

(3) Define SYMLOOP_MAX.

We need a definition for this if we don't have one and because it's
a new define we can pick the conservative and reliable value of 8.

Cheers,
Carlos.
-- 
Carlos O'Donell
Mentor Graphics / CodeSourcery
carlos_odonell@mentor.com
carlos@codesourcery.com
+1 (613) 963 1026


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]