This is the mail archive of the
mailing list for the glibc project.
Re: A per-user or per-application ld.so.cache?
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: libc-alpha at sourceware dot org, Ben Woodard <woodard at redhat dot com>
- Date: Mon, 8 Feb 2016 15:36:17 -0500
- Subject: Re: A per-user or per-application ld.so.cache?
- Authentication-results: sourceware.org; auth=none
- References: <56B8E105 dot 8030906 at redhat dot com> <56B8E810 dot 1040609 at redhat dot com> <56B8F860 dot 6060707 at redhat dot com> <56B8F9CC dot 4080205 at redhat dot com>
On 02/08/2016 03:25 PM, Florian Weimer wrote:
> On 02/08/2016 09:19 PM, Carlos O'Donell wrote:
>> Why would a long-lived process that uses dlopen fail to benefit from an
>> on-disk cache?
> It's not worth the complexity. (On top of the SUID issue already
> mentioned, there is also the question of cache invalidation.) With
> long-living processes, you could just read in the a designated list of
> directories at startup and use that to seed an ephemeral cache. Hence
> my question about the directory layout.
There is no added complexity? It's exactly the same code used by ldconfig
to generated /etc/ld.so.cache, but we extended it to untrusted directories,
and so must filter it based on the user. I admit it is a *little* bit of
Are you familiar with what goes into /etc/ld.so.cache? It is only a cache
of lookups, not the DSOs themselves, so we would be caching the results of
a search of the user directories and recording the DSOs found there, nothing
more. The user is already mostly accustomed to using ldconfig as root to
update the global cache, this is just an extension to allow ldoconfig to
be run by the user.
Right now it's just an idea, and I'm open to other solutions to the problem
of accelerating the DSO search path lookup and minimizing the number of
stats and directories traversals on potentially distributed filesystems.
>> Would you mind expanding on your concern that the solution would not work?
> It would work, it's just more difficult to use.
Would you mind expanding on what you would find difficult? Words like better
or worse, in a technical context, need explicit descriptions of what is
better and what is worse.
The user would have to run 'ldconfig', and perhaps by default we update the
user cache and skip updating the global cache if the user lacks the persmissions
to do so. Not that different from what we do today with Fedora/RHEL spec files
when libraries are installed.