Bug 819680 - librpmio.so exports bundled broken glob(3) clone
librpmio.so exports bundled broken glob(3) clone
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Fedora Packaging Toolset Team
Fedora Extras Quality Assurance
: Upstream
Depends On:
Blocks: 819682
  Show dependency treegraph
 
Reported: 2012-05-07 20:33 EDT by Frank Ch. Eigler
Modified: 2012-11-18 09:13 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 819682 (view as bug list)
Environment:
Last Closed: 2012-11-18 09:13:52 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Frank Ch. Eigler 2012-05-07 20:33:56 EDT
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 01:19:19 EDT
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 05:27:00 EDT
(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 06:33:13 EDT
(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 10:42:48 EDT
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 07:14:00 EDT
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 09:13:52 EST
Fixed in rawhide now as of rpm >= 4.10.90

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