Bug 866 - glob should match dangling symlinks
Summary: glob should match dangling symlinks
Status: NEW
Alias: None
Product: glibc
Classification: Unclassified
Component: glob (show other bugs)
Version: 2.3.5
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Depends on:
Reported: 2005-04-22 19:50 UTC by Steven Plite
Modified: 2017-03-06 22:33 UTC (History)
7 users (show)

See Also:
Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
Last reconfirmed:
fweimer: security-

fix globbing of dangling symlinks in sysdeps/generic/glob.c (834 bytes, patch)
2005-04-22 19:54 UTC, Steven Plite
Details | Diff
866-v2: updated patch that applies cleanly against master (788 bytes, patch)
2012-09-27 04:43 UTC, Tom Lee
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Steven Plite 2005-04-22 19:50:20 UTC
The 1.53 revision to sysdeps/generic/glob.c added a check for dangling symlinks.
 While necessary for directory globs, it still seems desirable to match dangling
symlinks in filename globs, as bash and tcsh's built-in globbers do.  This
program demonstrates the problem:

% cat globtest.c
#include <stdio.h>
#include <glob.h>

        int i;
        glob_t pglob;

        symlink("/nope", "foo1");
        symlink("/usr", "foo2");
        glob("foo[12]", 0, 0, &pglob);
        for (i = 0; i < pglob.gl_pathc; i++)
                printf("pglob.gl_pathv[%d] = \"%s\"\n", i, pglob.gl_pathv[i]);
% gcc -o globtest globtest.c
% ./globtest
pglob.gl_pathv[0] = "foo2"

Same thing in bash (tcsh behaves identically):

bash-2.05b$ cd /tmp
bash-2.05b$ ln -s /nope foo1
bash-2.05b$ ln -s /usr foo2
bash-2.05b$ echo foo[12]
foo1 foo2
bash-2.05b$ rm foo1 foo2

I'm attaching a patch to glob.c that makes glob()'s behavior mimic bash and
tcsh's.  The resulting glob() still passes globtest.sh, so it seems correct.
Comment 1 Steven Plite 2005-04-22 19:54:37 UTC
Created attachment 461 [details]
fix globbing of dangling symlinks in sysdeps/generic/glob.c

Adding another argument to glob_in_dir() was the easiest route, but perhaps one
of its existing arguments could be (ab)used instead.
Comment 2 Ulrich Drepper 2005-09-27 05:54:41 UTC
This behavior is correct.  There won't be any change.
Comment 3 Panu Matilainen 2012-05-08 11:25:28 UTC
Any chance of reconsidering this?
Comment 4 joseph@codesourcery.com 2012-05-08 11:50:50 UTC
If you believe a bug was inappropriately closed, you need to reopen it, or 
open a new bug for the same issue, preferably with detailed references to 
the appropriate standards or other reasons you think the closure was 
inappropriate.  Comments on closed bugs don't make the bugs appear to 
anyone subsequently doing bug triage.
Comment 5 Rich Felker 2012-05-08 16:43:12 UTC
This seems like yet another unexplained/unreasonable bug closure by Drepper. Can we please get a serious review of it. I think the fact that glob() is behaving differently from bash, and the fact that one expects "rm *" to remove everything including dangling symlinks, speaks for itself; POSIX does not have any special language about symlinks in the specification for glob, so by default I think it requires them to be included in the results.
Comment 6 Tom Lee 2012-09-27 04:43:17 UTC
Created attachment 6655 [details]
866-v2: updated patch that applies cleanly against master

Here's an updated version of Steven's patch that applies cleanly against the current master branch in case anybody wants to play with it.

Seems to work well, but I'm new here -- not sure what the policy is wrt tests?
Comment 7 Michael Matz 2017-03-06 14:59:47 UTC
Just one more data point, we got a customer also being surprised by this
divergence from shell behaviour when all existing documentation suggests
that it should match.  So, to get all info in one place, the redhat report


our (https://bugzilla.novell.com/show_bug.cgi?id=1026911) is unfortunately
inaccessible to the outside, but describes exactly this issue with essentially
the same testcases.