Re: A per-user or per-application ld.so.cache?

["Carlos O'Donell" <carlos 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
added complexity.

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.

Cheers,
Carlos.