Re: The future of static dlopen

[Florian Weimer <fweimer at redhat dot com>]

On 12/20/2017 05:36 PM, Zack Weinberg wrote:
> On Tue, Dec 19, 2017 at 11:24 PM, Florian Weimer <fweimer@redhat.com> wrote:
> > On 12/20/2017 08:03 AM, Carlos O'Donell wrote:
> > > It would be easiest to have a proxy process to handle these requests
> > > for you... such a proxy process could be a proxy thread instead?
> > > As you suggest earlier have the kernel start a new tid, and map into
> > > your VMA a new dynamic executable that you can access and call into
> > > for services?
> >
> > I would just add an option to /usr/bin/getent which causes it to enter
> > co-process mode.  It's not going to be extremely efficient (especially if we
> > don't use a persistent subprocess, but it would be quite reliable, unlike
> > what we have to day).
>
> This seems like another case where making nscd less of an afterthought
> would be a win.  It already does this job, after all.

I don't think nscd takes care of everything.  Enumeration is missing, I 
think, and so are some databases (aliasent, etherent).

> In principle,
> static binaries could just omit the no-nscd fallback path.  (In
> practice, falling back to "files [dns]" might be the right thing,
> since static binaries tend to get used for recovery.)

I thought about that as well, but I'm really not sure if using nscd 
brings a benefit.  From a distribution perspective, if you have to 
install nscd to run certain satic libraries, that might also enable it 
for dynamically-linked binaries, and many users may not want that.

Thanks,
Florian