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.