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