Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 30 Mar 2018 13:54:11 -0500
From: William Pitcock <nenolod@...eferenced.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] resolv.conf parser: concatenate multiple search
 domain lines

Hello,

On Fri, Mar 30, 2018 at 8:21 AM, Rich Felker <dalias@...c.org> wrote:
> On Fri, Mar 30, 2018 at 02:27:42PM +0200, Quentin Rameau wrote:
>> Hi William,
>>
>> > Programs such as Docker and Kubernetes write multiple domain search
>> > lines, such as
>> >
>> > search serious-business.big-data.prod.foo.com
>> > search big-data.prod.foo.com
>> > search prod.foo.com
>> >
>> > instead of
>> >
>> > search serious-business.big-data.prod.foo.com big-data.prod.foo.com
>> > prod.foo.com
>> >
>> > Accordingly, we concatenate the namelist together so that the search
>> > path is not truncated.
>>
>> I think this patch should be sent to Docker and Kubernetes instead of
>> pushing a mitigation for their bug in the libc.
>>
>> According to documentation, “The domain and search keywords are
>> mutually exclusive.  If more than one instance of these keywords is
>> present, the last instance wins.”
>>
>> This patch would break existing applications relying on documented
>> behaviour.
>
> I wrote the current behavior based on that documentation. Apparently
> the current glibc behavior does not match the documentation, but I'd
> really rather not go against the documentation unless there's
> agreement from glibc/others that the documentation is wrong and their
> current behavior is desired. Either way I think Docker/Kubernetes
> should fix this, since it's ambiguous what the "right" thing to do is
> and there very well could end up being inconsistent behaviors between
> libcs/versions into the future.

It turns out this problem has been fixed a while ago.  The actual
problem is something else, which I was able to reproduce.
I sent a patch for it, too.

William

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ