Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 3 Dec 2013 16:38:29 -0500
From: Rich Felker <>
Subject: Re: _PATH_LASTLOG

On Tue, Dec 03, 2013 at 08:44:01PM +0000, Laurent Bercot wrote:
> >One problem I'd like to solve is making a way for users to override
> >the system resolv.conf;
>  The s6-dns client library uses the DNSCACHEIP environment variable for
> this: if it contains a list of DNS caches, this list will override the
> /etc/resolv.conf-provided one. (The idea comes from djbdns, but has been
> extended to a full list instead of a single cache address.)
>  Same thing with the DNSQUALIFY environment variable, which can have
> a list of suffixes that overrides resolv.conf. (djbdns had a complex
> rules-rewriting-based qualification mechanism that nobody ever used,
> so the simpler approach was easier and better.)
>  Maybe musl could use the same approach: environment variables are a
> reasonable place for hardcoded-path overrides. But it has to be balanced
> against namespace pollution.

Indeed. If we go with environment variables, I'd like to aim to avoid
reinventing the wheel and use something already supported elsewhere.
But as far as I can tell, other libcs don't offer such a feature, and
it's questionable whether we should be using variables that were
"intended" (by a third party library) to affect that library and not
libc. This is an area we really need to do more research in to
determine a safe solution. (BTW, whatever we do, suid programs
( != 0) should always ignore the custom setting.)

> >There are LOTS of ways one could extend hostname lookups, ranging from  NSS modules to
> >hosts.d and resolv.d, but rather than trying to support everything
> >imaginable (result: bloat and serious security considerations) in
> >libc, the musl approach to hostname lookup is that libc contains the
> >basics that are suitable for most/all simple systems, and anything
> >more advances can be provided by an external daemon running on
> >localhost that speaks DNS protocol and provides whatever lookup
> >semantics you desire.
>  In the DNS case, the flexible - and best, IMNSHO - approach is to run a
> small local DNS cache on localhost indeed; but the problem is that there's
> an existing codebase that sometimes insists on clobbering /etc/resolv.conf,
> which adds to the packaging burden when your purpose is to create or maintain
> a distribution. Having extension mechanisms at the libc level can help in
> that situation.

chattr +i is your friend. :-)


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.