[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20131203213829.GQ24286@brightrain.aerifal.cx>
Date: Tue, 3 Dec 2013 16:38:29 -0500
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
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
(libc.secure != 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. :-)
Rich
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.
