| Summary: | RFE Avoid polluting user namespace with DSOs loaded by implementation. | ||
|---|---|---|---|
| Product: | glibc | Reporter: | Pedro Alves <pedro> |
| Component: | libc | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | NEW --- | ||
| Severity: | normal | CC: | carlos, drepper.fsp, fweimer |
| Priority: | P2 | Flags: | fweimer:
security-
|
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| See Also: | https://sourceware.org/bugzilla/show_bug.cgi?id=19884 | ||
| Host: | Target: | ||
| Build: | Last reconfirmed: | ||
| Bug Depends on: | 18684 | ||
| Bug Blocks: | |||
|
Description
Pedro Alves
2014-04-29 12:17:29 UTC
Florian Weimer and I had a dicussion about this last year. In the general case there is no other option except to track and enforce the global namespace of all libraries and exported symbols for the entire distribution and avoid overlap. Note that LSB does some of this by standardizing the exported symbol lists. Florian had a database that he constructed to test for these kinds of things. The discussion ends here where we both agree that no amount of tooling will fix this, but the tooling will help mitigate the problems: https://sourceware.org/ml/libc-help/2013-12/msg00010.html There may be some amount of dlmopen() usage that we can do to ensure the implementation loaded modules are hidden from the user modules, but eventually the breakage will happen and the only solution is to alter the linkage scope (drawing a wall around things) or fix the symbols. Does that make sense? Retitled to reflect RFE nature. This is being discussed here: https://sourceware.org/ml/libc-alpha/2016-04/msg00130.html The only solution to this is to use dlmopen to load the NSS modules to isolate the 3rd party objects from the application, similarly for libgcc's use for unwidnding. This is blocked on fixing 18684 which should get dlmopen working correctly. For reference, the original gdb bug report was further clarified and discussed here: https://sourceware.org/ml/libc-alpha/2016-04/msg00130.html (GDB is now carrying a workaround for the Python bug that makes gdb export all its symbols in the dynamic table, which then in turn exposes the NSS module's namespace pollution. That workaround works as long as GDB is not configured against a static Python: https://sourceware.org/ml/gdb-patches/2016-04/msg00246.html) Roland's suggestion for tooling was interesting: (...) the case you hit was in a third-party NSS module. Obviously we can't ourselves do anything directly about the quality of third-party modules. But we could potentially provide a tool to vet third-party modules for our name space rules. |