This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 3/9] posix: Allow glob to match dangling symlinks [BZ #866]
On 09/09/2017 19:01, Paul Eggert wrote:
> Adhemerval Zanella wrote:
>> since make also packs
>> its own glob copy from gnulib, it is matter to fix on make if and when
>> it syncs with gnulib.
>
> No, GNU Make uses glibc glob if it passes the compatibility tests in
> 'configure', which it does. So previously-built instances of GNU make
> will likely crash if run with a glibc containing the proposed symlink
> changes. Even if you rebuild GNU Make from scratch it will still
> crash, because glibc glob will pass GNU Make's tests even with the patch.
>
> We could fix this by incrementing _GNU_GLOB_INTERFACE_VERSION to 2
> (causing GNU Make's configure-time test to fail), but this is a
> serious step that requires changing the libc.so major version number,
> creating backwards-compatibility functions for the old behavior, etc.
> I doubt whether the symlink glitch with 'glob' is worth all this effort.
>
> How about the following idea instead: establish two new flags
> GLOB_FOLLOW and GLOB_NOFOLLOW, where the caller specifies whether
> symlinks should be followed. The default is system-dependent. For
> glibc the default is GLOB_FOLLOW (we can even make GLOB_FOLLOW zero).
> For FreeBSD the default would be GLOB_NOFOLLOW, assuming they like the
> idea of supporting these flags. This maintains backward-compatibility
> for both kinds of platforms. For application code preferring
> GLOB_NOFOLLOW semantics if available, a simple:
>
> #include <glob.h>
> #ifndef GLOB_NOFOLLOW
> # define GLOB_NOFOLLOW 0
> #endif
>
> will do, as long as all calls go glob specify 'GLOB_NOFOLLOW'. We can
> implement this idea first in Gnulib and then propose it for glibc.
>
> Anyway, I'll submit a bug report to GNU Make, since it should not be
> assuming this implementation detail of glibc, regardless of what we
> decide about the above matter. However, it will be at best many years
> before we can assume this bug is fixed in the wild.
I would prefer to avoid adding a new flag, but for this specific issue I
do not see a better
solution (as you have said I also agree bumping interface version does
not worth the
trouble). What really bothers me is the motivation to actually support
it is to maintain
compatibility with a undefined use of a not well documented interface
(which imho is
clearly a bug in 'make' usage). This will be another adhoc gnu
extension, which
most likely won't be used anywhere besides on make itself (and the
system-dependent
semantic will also lead to more confusion).
Another option is to add a compat glob symbol with previous semantic
(without
actually bumping _GNU_GLOB_INTERFACE_VERSION). It still won't help new
'make'
builds against newer glibc (not without fixing make anyway), so I am not
sure if
is feasible solution.