From patchwork Fri Feb 8 17:52:45 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Heitor Alves de Siqueira X-Patchwork-Id: 1038874 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=sourceware.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=libc-alpha-return-99880-incoming=patchwork.ozlabs.org@sourceware.org; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=canonical.com Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.b="dXEFVBPA"; dkim-atps=neutral Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 43x2pt3SWLz9sMp for ; Sat, 9 Feb 2019 04:53:26 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:cc:subject:date:message-id; q=dns; s= default; b=epsQNWBxlcuIY5ymQt/9FBEg4pzkPNwaComSXvhzGzZEngurmV53C Ce45BrPP+fLPCi/ZLClylQzLdOsBsBzHLYw603IXGYER4+KX9FFVIaEqDXuDlIFS K/9FwlcT8aoIkzM09C1fU2Gy5zdWBuFAYxILj4imS79KVZPT3KOzng= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:cc:subject:date:message-id; s=default; bh=fTiZgQy2rWXgB8mCt6ucFOrgtpw=; b=dXEFVBPAOOUFHnTC0Pn/6lBeccSQ bzrI207WIhanXuqsDZtQwPGBvO7p6CDtA+W7W2IcQYvz4BjJnThqHa10W6MQY1X9 6b2U+FTwqQz9oIHXLrvTWlcjO0T9eYO+kbU+PVQ44waJpf70snegf2/UD8gEExdj AE7vCaliUE2mK0M= Received: (qmail 10863 invoked by alias); 8 Feb 2019 17:53:20 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 10848 invoked by uid 89); 8 Feb 2019 17:53:19 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-25.9 required=5.0 tests=BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, KAM_LAZY_DOMAIN_SECURITY autolearn=ham version=3.3.2 spammy=Force, getaddrinfo, wrt, family X-HELO: youngberry.canonical.com From: "Heitor R. Alves de Siqueira" To: libc-alpha@sourceware.org Cc: Florian Weimer , Dan Streetman , "Heitor R. Alves de Siqueira" Subject: [RFC PATCH] getaddrinfo: Force name resolution for AI_CANONNAME [BZ# 24182] Date: Fri, 8 Feb 2019 15:52:45 -0200 Message-Id: <20190208175245.2314-1-halves@canonical.com> When getaddrinfo() is called with a numeric nodename argument (e.g. 67882190), we should try name resolution if AI_CANONNAME is set. RFC 1123 allows digits-only hostnames, but inet_aton_exact() can interpret these as valid IPv4 addresses in a 32-bit number form. This behaviour causes the internal gaih_inet() call to think a numeric hostname is a valid IPv4 address and skip name resolution. One can reproduce this by following these steps: 1) Append numeric hostname records to /etc/hosts: $ head -n2 /etc/hosts 127.0.0.1 localhost 127.0.0.1 1234.example.com 1234 2) Change local hostname to the numeric record: $ sudo hostname 1234 3) Call `hostname -f` (output should be '1234.example.com'): $ hostname -f 1234 This patch forces name resolution if the AI_CANONNAME flag is set. Even if inet_aton_exact() identifies the input name as being a valid IPv4 address, we will try name resolution in case it's a valid hostname. If no hostname is found after resolution, the input name is still copied to the ai_canonname field. The patch was tested on amd64, and the glibc test suite showed no regressions. Further use case tests showed that current behaviour is not modified w.r.t. IPv4 addresses. --- This is a tentative patch suggestion for BZ# 24182. The general idea is already being discussed there, but I would like some more thoughts on the patch specifically, if possible. Likely there are many ways to tackle this and I'm unsure which would be best suited. Thanks! Heitor sysdeps/posix/getaddrinfo.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/sysdeps/posix/getaddrinfo.c b/sysdeps/posix/getaddrinfo.c index aa054b620f2a..fa9e2d6ad3b1 100644 --- a/sysdeps/posix/getaddrinfo.c +++ b/sysdeps/posix/getaddrinfo.c @@ -505,9 +505,6 @@ gaih_inet (const char *name, const struct gaih_service *service, result = -EAI_ADDRFAMILY; goto free_and_return; } - - if (req->ai_flags & AI_CANONNAME) - canon = name; } else if (at->family == AF_UNSPEC) { @@ -548,7 +545,8 @@ gaih_inet (const char *name, const struct gaih_service *service, } } - if (at->family == AF_UNSPEC && (req->ai_flags & AI_NUMERICHOST) == 0) + if ((at->family == AF_UNSPEC || (req->ai_flags & AI_CANONNAME)) + && (req->ai_flags & AI_NUMERICHOST) == 0) { struct gaih_addrtuple **pat = &at; int no_data = 0;