Bug 819680 - librpmio.so exports bundled broken glob(3) clone
Summary: librpmio.so exports bundled broken glob(3) clone
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Fedora Packaging Toolset Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 819682
TreeView+ depends on / blocked
 
Reported: 2012-05-08 00:33 UTC by Frank Ch. Eigler
Modified: 2018-04-10 07:42 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 819682 (view as bug list)
Environment:
Last Closed: 2012-11-18 14:13:52 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Frank Ch. Eigler 2012-05-08 00:33:56 UTC
librpmio, going back to bug #134362, exports a glob(3) implementation on its shared library that behaves differently from glibc's.  It calls its own glob ... glob ... which can break programs if they link in -lrpmio.  This affects every recent fedora and rhel.

rpmio should have bundled a copy of the ancient glibc glob() under a different name, like rpmGlob.  Or it could have stopped bundling when glibc's original symlink-related bug/behavior was changed.  Or it can ensure that its glob is __attribute__((visibility,hidden)) from other compilation units.  Or something.

To reproduce e.g. on f16:

% mkdir foo
% cd foo
% cat > foo.c
#include <glob.h>
#include <stdlib.h>
#include <string.h>
int
main ()
{
  glob_t g;
  memset (&g, 0, sizeof (g));
  int ret = glob ("./lib*/libc-*.so*", 0, NULL, &g);
  __builtin_printf ("%d %d\n", ret, g.gl_pathc);
  return 0;
}
^D
% ln -s /lib lib
% ln -s /lib64 lib64
% ls ./lib*/libc-*.so*
[... found files ...]
% gcc foo.c
% ./foo.c
0 2         <<---- ie libc found, all happy
% gcc foo.c -lrpmio
% ./foo.c
3 0         <<---- ie libc not found when searching through symlinks

Comment 1 Panu Matilainen 2012-05-08 05:19:19 UTC
Yup, blasts from the past...

So is glibc glob() now returning dangling symlinks again? If so, when did it change?

Comment 2 Mark Wielaard 2012-05-08 09:27:00 UTC
(In reply to comment #1)
> Yup, blasts from the past...
> 
> So is glibc glob() now returning dangling symlinks again? If so, when did it
> change?

No it is not.

#include <glob.h>
#include <stdlib.h>
#include <string.h>
int
main ()
{
  glob_t g;
  memset (&g, 0, sizeof (g));
  int ret = glob ("*foo*", 0, NULL, &g);
  __builtin_printf ("%d %zu\n", ret, g.gl_pathc);
  return 0;
}

$ ln -s barfoobaz bazfoobar
$ ./glob
3 0

Doesn't match, but
$ ln -s /dev/null bazfoobaz
0 1

Does match.

See http://sourceware.org/bugzilla/show_bug.cgi?id=866
But you might want to ask on the bug whether or not it may be reopened, the new glibc team has been revisiting old bug reports to see if any have been closed in error in the past.

In any case, librpmio.so really should not export its own glob() implementation. It causes odd behaviour like for the testcase from the description where the rpm version of glob is broken (and that setup with /lib and /lib64 being symlinks is the default after usrmove in F17).

Comment 3 Panu Matilainen 2012-05-08 10:33:13 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > Yup, blasts from the past...
> > 
> > So is glibc glob() now returning dangling symlinks again? If so, when did it
> > change?
> 
> No it is not.

Right. Would've been shocked to learn otherwise...

> See http://sourceware.org/bugzilla/show_bug.cgi?id=866
> But you might want to ask on the bug whether or not it may be reopened, the new
> glibc team has been revisiting old bug reports to see if any have been closed
> in error in the past.

Dunno if its worth the trouble. Even if the behavior got changed one of these days, rpm would still have to support versions with the current behavior for years to come.

> In any case, librpmio.so really should not export its own glob()
> implementation.

No disagreement there, just perhaps mildly surprised to see somebody actually complain about it after all the years its been that way (I've known, intended to fix and forgotten about it at least five times by now :)
I'd rather get rid of the internal implementation in the first place but...

Comment 4 Mark Wielaard 2012-05-08 14:42:48 UTC
BTW. Two different solutions to work around the broken glob in librpmio.so for programs linking against it:

http://sourceware.org/bugzilla/show_bug.cgi?id=14078

The first allows librpmio to use its own glob, the second just overrides it with the one from glibc.

Comment 5 Panu Matilainen 2012-06-01 11:14:00 UTC
FWIW this has been fixed upstream git master now. For released rpm versions we'd probably want a bit less invasive fix though.

Comment 6 Panu Matilainen 2012-11-18 14:13:52 UTC
Fixed in rawhide now as of rpm >= 4.10.90

Comment 7 Florian Weimer 2018-04-10 07:42:02 UTC
(In reply to Panu Matilainen from comment #1)
> Yup, blasts from the past...
> 
> So is glibc glob() now returning dangling symlinks again? If so, when did it
> change?

It changed in glibc 2.27 (Fedora 28), where this bug was fixed:

https://sourceware.org/bugzilla/show_bug.cgi?id=866


Note You need to log in before you can comment on or make changes to this bug.