[PATCH 9/9] posix: Fix glob with GLOB_NOCHECK returning modified patterns (BZ#10246)

[Adhemerval Zanella]

On 08/09/2017 00:14, Paul Eggert wrote:
> Although this is a definite bug and the patch fixes this instance of
> it, I'm afraid other instances remain unfixed. For example:
>
>    glob_t g; glob ("//a*b", 0, NULL, &g)
>
> can do the wrong thing, since glob calls opendir on "/" instead of
> "//", and on some platforms "/" and "//" are different directories
> (POSIX allows this as a special exception).
>
> A more serious example. If you do this:
>
>   ln -s /no-such-file globlink1
>   ln -s . globlink2
>
> then:
>
>       glob_t g;
>       int res = glob ("globlink[12]/", 0, NULL, &g);
>       assert (res == 0 && g.gl_pathc == 1);
>       assert (strcmp (g.gl_pathv[0], "globlink2/") == 0);
>
> fails, since glob gets confused about directories and slashes and
> mistakenly returns two results. Although this bug is seemingly
> unrelated, the underlying cause is the same: glob gets confused about
> whether to include or exclude slashes when doing its tests.
>
> I'll take a look at it, though the fix won't be trivial.
>
> PS. This finishes my review of this patchset. Patches 1-8 are OK to be
> installed, with the trivial changes I suggested earlier. This patch
> (patch 9) I'd like to hold off on, until we've had a chance to work
> out a more-comprehensive fix.
Fair enough, I will hold patch 9 push and take a look at the examples you
brought up.  Thanks for the follow up.

>
> PPS. I'm still slowly wending my way through your original patchset.
> Most recently I looked at "[PATCH 07/18] posix: User LOGIN_NAME_MAX
> for all user names in glob"
> <https://sourceware.org/ml/libc-alpha/2017-08/msg00447.html>. I'm
> afraid a good fix needs to be hairier there too, as POSIX does not
> require LOGIN_NAME_MAX to be suitable for a stack-based buffer, or
> even to be defined. I have a partly-drafted patch which I hope to
> finish in the not-too-distant future.
Alright, my initial patch was to adequate it to glibc code (which does
define a actual limit suitable to stack allocation) and get rid of any
alloca usage.  My understanding, based on gnulib commit 064df0b0c,
is it should not impose a limit on user name length. 

So currently in a patchset I am intended to send after this one, user
name handling is now based on my char_array struct and thus allocates
the user_name dinamically if required.