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

[Carlos O'Donell]

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...

It is not just about resolv.conf, the point is to avoid all the other
problems you may also run into. The point is to provide you with a robust
solution so you don't have to come back for all the other environment
variables you may need to tweak the runtime.

For each of these environment variables there is security risk, auditing
issues, maintenance costs etc.

> 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.

> resolv.conf is just a configuration file of the library. A security
> model based on the idea that something is safe because the library
> forbids the access to a functionality is weak. System calls must
> enforce processes to behave correctly, system calls can really forbid
> bad behaviors. When a syscall says no it is no. Users can run
> different libraries if it is just the library to deny something.

Reductio ad absurdum is not valid here, there are layers of security
and core userspace libraries play a key role here in providing security.
 
> So, why not providing a linear and straightforward simple way to
> solve a simple problem?

It adds to the overall complexity of the library, and makes it harder
to know how to correctly configure your application and know exactly
where it will get resolver information from.

Users are already deploying containers to solve other problems and
if your solution dovetails nicely into this, then they will appreciate
that.

> Providing complex methods only, does not make the system safer but
> prevents developers from writing services or at least from writing
> good clean code to implement their services. Isn't it?

Making there only be 1 way to set the resolver configuration makes it
easier for application developers, and administrator to administer
their systems.

Using namespaces, including mount namespaces, could be made easier.
There is an argument for that, but this argument should not apply
as the reason for making there be 2 ways to set the resolver information.
This complicates configuration and debugging for users.

If anything I would focus on making namespace easier :-)

--
Cheers,
Carlos.