Re: Enable linknamespace testing for libdl and libcrypt

[Florian Weimer <fweimer@redhat.com>]

On 11/17/2016 03:31 PM, Joseph Myers wrote:
> On Thu, 17 Nov 2016, Florian Weimer wrote:
>
>>> Assuming there are no implementation-namespace exports of those functions
>>> that libcrypt could use instead, that indicates whitelisting in
>>> linknamespace.pl with a comment referencing a bug filed for nss-crypt
>>> namespace issues.
>>
>> Well, this is only relevant if we actually had a libfreebl.a which defines the
>> functions above.  I don't think such a thing exists.  Fedora and downstreams
>> don't have it, and neither does Debian jessie.
>
> As a cross-library namespace issue I'd expect it's just as relevant when
> shared libcrypt is referencing these functions from another shared
> library.

This is correct.  The library with the NSSLOW_* names is just a stub, 
and it attempts to dlopen the real thing (without RTLD_GLOBAL), to 
conserve the symbol footprint.  But that library uses quite a few 
functions which may have been interposed by the application, and 
RTLD_LOCAL does not guard against that.

Note that moving these libraries into the implementation namespace is 
counterproductive because we don't want non-toolchain libraries to be 
located there because then we don't own that space anymore and cannot 
argue that names in it are safe to use for us.  But such low-level 
libraries (libidn will be in the same boat soon) could certainly use 
glibc functionality under names in the implementation namespace without 
ill effect.

For the symbols they define, we need to make sure (at the distribution 
level) that these symbols are reasonably prefixed in some way.  Names 
like “mutex“, “buffer”, ”yyin” are really not a good idea.

> That is, this configuration involves a namespace bug,

Agreed.

> which is  hard to fix so the names in question are whitelisted.

Sorry, I don't understand this part.

Florian