This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug nss/24939] Please support per-user configuration (resolv.conf, hosts)


https://sourceware.org/bugzilla/show_bug.cgi?id=24939

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |carlos at redhat dot com
         Resolution|---                         |WONTFIX

--- Comment #1 from Carlos O'Donell <carlos at redhat dot com> ---
This needs to be discussed in detail on libc-alpha, and the pros/cons
evaluated. If you get positive feedback on libc-alpha please reopen this bug. 

You are asking for a feature and that feature carries with it maintenance cost
that carries on for the lifetime of the project. Therefore the feature needs to
be very important and lower cost relative to other solutions.

Unfortunately the design of a per-user configuration for resolv.conf+hosts is
difficult to apply it consistently to a process tree. For example users don't
just want one process to see a per-user configuration they want a constellation
of processes to see the same resolution. In my experience it's rare that it's
just one process.

The solution used today is a container and the isolation is simply much better
this way. We use containers in glibc for testing /etc/resolv.conf and hosts
changes. Container tooling is mature and easy to use. There is even non-root
container tooling now (podman). There is really no excuse to list containers as
a difficult solution to this problem.

As a GNU C Library maintainer I'm marking this RESOLVED/WONTFIX as a solution
that is costly to implement and already has a solution with containers on
Linux. 

Alternatives include writing and providing your own NSS module which can
provide the same behaviour. This is why the NSS subsystem is pluggable so you
can extend it in any way you wish.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]