On Jul 29, 2008, at 4:23 PM, Arkadiusz Miskiewicz wrote:
Hello,
Current glob() approach is unfortunately broken on Linux systems
that use
shared librares (and sometimes --as-needed).
The glibc glob.h header on 64bit is doing:
# define glob glob64
which means glob in rpmmisc is not used.
On 32bit without largefile enabled there is another problem - --as-
needed flag
causes that linker will happily avoid linking to librpmmisc because
glibc
already provides glob() symbol. In the end glibc glob() will be used.
These issues can be solved by explictly renaming glob to for
example rpm_glob
(+ rpm_globfree + rpm_glob_t type). Then it's 100% sure that
internal glob
will be used and no symbol clash can happen.
Since the issues involved here are rather arcane, I should add some
historical context.
The rpmbuild failure symptom (using linux glibc glob(3)) is
System glob(3) fails to pick up dangling symlinks mentioned in %
files through a glob.
The fundamental incompatibility is due to a (necessary imho) security
fix
that introduced a glibc incompatibility. Meanwhile rpmbuild is expected
to behave as always, in spite of glibc changing behavior.
There are (at least) the following known work arounds that have been
tried:
0) change rpmbuild expectations to document that dangling symlinks
mentioned
through globs are explicitly unsupported. Use an absolute file path,
not a glob, when packaging
dangling symlinks instead.
1) use internal glob(3)
This was done in rpm-4.4.2 as a stop-gap remedy at the time, but its
really
hard to imagine better, the issue of glob(3) behavior on dangling
symlinks
is totally uninteresting.
2) use the GNU extensions to revert system glob(3) to the previous
behavior.
SuSE has followed this approach, loading the system glob(3) behavior
with
Lstat(2) instead of Stat(2), essentially reverting to the previous
"no follow"
behavior of glibc.
3) (untried afaik) linking to the previous version of glob(3) symbol
in glibc.
This would likely succeed.
Only 0) actually solves the security issue of glob'ing dangling
symlinks.
Noone has cared to attempt or suggest the 0) approach for 3+ years.
That would seem to indicate that preserving rpmbuild expectations is
more important than solving security issues in rpmbuild. Again, the
issue
of using glob(3) underneath %files on a build system is hardly
meaningfully
exploited imho, there are far easier paths to root available than
trying to
exploit a dangling symlink on a build system.
There are other portability issues, mostly wrto what flags are
available (and
what the numerical values map to) that have always been present in
spite of
POSIX and standards.
So internalizing glob(3) as Glob(3), with an internal Glob_t, and
dragging in Fnmatch(3)
and the other symbols, seems perhaps the optimal solution for a
problem that
is directly causes by incompatibilities introduced in system, not
rpm, libraries.
Other opinions welcomed.
73 de Jeff
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
