Re: [PATCH] resolv/resolv.h: allow alternative resolv.conf files

[Carlos O'Donell <carlos at redhat dot com>]

On 08/22/2017 05:37 AM, Renzo Davoli wrote:
> I have released userbindconf, a library and a utility command to
> bind-mount files and directores in user-namespaces.
> https://github.com/rd235/userbindmount
> 
> Nevertheless, the whole stuff sounds as a workaround to me.
> 
> On Fri, Aug 18, 2017 at 12:41:50PM -0400, Carlos O'Donell wrote:
>> On 08/18/2017 11:07 AM, Renzo Davoli wrote:
>>> It seems a bizantine procedure just to tell resolv to use a different
>>> resolv.conf.
>> I agree, but that's not the extent of this...
> ...
>>> There is some extra work for the kernel (keep track of the new
>>> namespaces, separate mounttables, more mount items) for a problem
>>> that could be solved entirely at user level.
>> Yes, you are right.
>> You are paying the cost for a design abstraction.
>>
>> Design abstractions make it easier for your users to know how your
>> systems work without needing to learn something new e.g. a new
>> environment variable.
> 
> An abstraction should be a simple concept able to represent a wide
> range of situations. Astractions should be simpler than the 
> "abstracted" concepts.

I agree.

> Using complicated methods to override a lack of generalization of
> the lower layer is more a "distraction" than an "abstraction".

There is a difference between the high-level abstraction and how it
is implemented. You may not like the complexity of the present
implementation, but the abstraction remains.

> There are several environment variables already in glibc to
> configure the name resolving process:
> RES_OPTIONS, RESOLV_ADD_TRIM_DOMAINS RESOLV_MULTI 
> RESOLV_OVERRIDE_TRIM_DOMAINS RESOLV_REORDER 
> RESOLV_SERV_ORDER RESOLV_SPOOF_CHECK 
> 
> What to say about:
> RESOLV_HOST_CONF
> ?

They exist because there was no other per-process solution, and
because glibc is backwards compatible we must keep them forever.

That doesn't mean they are a good design for today.

> It redefines the path to be used instead of /etc/host.conf.
> Isn't this very close to what I proposed as PATH_RESCONF?
> (which could be renamed as RESOLV_RESCONF to be consistent
>  with the others).

Yes it does.
 
> Is there really the need for a user-namespace for a so simple
> (and common) generalization?

Need is difficult to answer. There are performance, maintenance,
and security implications to take into account.

> Timezones and locales should be implemented as "abstractions"
> requiring namespaces if this is the idea, isn't it?
> Try to think on how complex would be the management of
> timezones and locales it this was the case...

Reductio ad absurdium should not be used to argue the technical
merits of a new interface, the old interface already exists and
may not be a good example of modern design.

Locales *are* being implemented in containers exactly how you
envision them. Thin containers provisioned with only C.UTF-8
(which several distros offer) are setup to provide microservices
which never need other locales (reduces QA and testing).

The locale, timezone, and resolver states can all be made
thread-local. This makes it harder to avoid providing all locales
for selection by threads which need specific languages to provide
those services in the language needed. Similarly some threads may
operate on different timezone data and so need all the timezone
data. Lastly, likewise different threads could use different
resolver state, you just need to configure it.

I see three solutions present today:

(a) Per-thread: Modify _res to get per-thread state. May go away
    some day, but backwards binary compat will always exist.

(b) Per-process / Per-thread:
    Alternate resolver library e.g. flexible DNS client library.
    The glibc resolver API is a standards compatible no-frills stub
    resolver.

(c) Per-process: mount namespace which overrides /etc/resolv.conf
    for your process.

-- 
Cheers,
Carlos.