From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 120014 invoked by alias); 2 Aug 2019 17:21:35 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 120004 invoked by uid 89); 2 Aug 2019 17:21:35 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=H*f:sk:13914.1, H*i:sk:13914.1 X-HELO: mx1.redhat.com From: Florian Weimer To: David Howells Cc: jlayton@redhat.com, libc-alpha@sourceware.org Subject: Re: Can getaddrinfo() be extended to return the record TTL References: <13914.1564764142@warthog.procyon.org.uk> Date: Fri, 02 Aug 2019 17:21:00 -0000 In-Reply-To: <13914.1564764142@warthog.procyon.org.uk> (David Howells's message of "Fri, 02 Aug 2019 17:42:22 +0100") Message-ID: <87v9vfcwkm.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2019-08/txt/msg00051.txt.bz2 * David Howells: > The Linux kernel has an upcall to get name -> address mappings for > network filesystems. The userspace side (key.dns_resolver.c in > keyutils) uses getaddrinfo() to perform the lookup as this gives a > greater range of sources than, say, using res_send(), giving access to > NIS, YP, LDAP, files or whatever, but getaddrinfo() does not include > any expiry information for the information. > > The userspace side of the upcall *should* be setting the expiry time > on the record - but it can't as the C library doesn't give us that > (and, indeed, it's not available from all sources). Is this merely a correctness thing, or does this enable some user-visible functionality? > Anyway, looking at getaddrinfo(), it looks like the addrinfo struct should be > extensible. Perhaps a flag, say AI_EXTENDED, could be provided that indicates > that is replaced with a larger struct that has additional fields such as > expiry time and a flag, AI_HAS_EXPIRY that indicates if the expiry time is > actually set. I think we would add accessor functions for that, along with an internal flag, so that gain some flexibility in the representation. In previous discussions, it was suggested just to increase the size of struct addrinfo, but this is not something we can do in glibc. > This looks like it should work as the result records appear to be in a list > rather than being an array. Due to the existence of freeaddrinfo, we can use the pointer itself as a hash table key as a last resort. > Another possible additional field would be a source indicator of some kind > that says where the data came from (e.g. 0=file, 1=dns, 2=yp, 3=ldap, ...). Interesting. It probably would have to be the name of the service module (not a number). Beyond the TTL, the security status was brought up as a suggestion. > If it's not possible to extend getaddrinfo() in this way, would it be possible > to provide a getaddrinfo2() that returns this information through an > additional parameter? That definitely would be a new ABI. New ABIs have a lead time of around three years before productization. Is this something you could work with? Thanks, Florian