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 R. Alves de Siqueira" X-Patchwork-Id: 31361 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;