| Summary: | Caching _dl_library_path is invalid | ||
|---|---|---|---|
| Product: | uClibc | Reporter: | Aleksander Wabik <awabik> |
| Component: | Standard Compliance | Assignee: | unassigned |
| Status: | NEW --- | ||
| Severity: | normal | CC: | awabik, uclibc-cvs |
| Priority: | P5 | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Linux | ||
| Host: | Target: | ||
| Build: | |||
| Attachments: | The workaround patch that makes things work correctly, although may be suboptimal solution | ||
Created attachment 5372 [details] The workaround patch that makes things work correctly, although may be suboptimal solution uClibc caches LD_LIBRARY_PATH env variable value in _dl_library_path, causing two bugs: 1. Caching the pointer obtained from getenv() is forbidden, as the application may change the environment afterwards, rendering the pointer invalid. In our case the application is modifying the environ global variable by calling setproctitle() (a function not present in uClibc, but provided by other library), and then the cached _dl_library_path in uClibc contains program's command line instead of the LD_LIBRARY_PATH value. 2. Caching such an env variable in any correct way which fixes problem 1 (eg. by doing strdup()) is non-spec anyway, and should not be done. The application may modify LD_LIBRARY_PATH and call dlopen() afterwards. It should cause reading the modified LD_LIBRARY_PATH instead of using the cached value. We currently use a workaround in libdl.c (see attachment), but a correct fix would be to make _dl_library_path variable local.