resolv: add IPv6 support to inet_net_pton()
Checks
Commit Message
Dear all,
This changeset adds support to inet_net_pton() to convert IPv6 network
numbers (IPv6 prefixes with CIDR notation) from presentation format to
network format.
The starting point of this changeset was OpenBSD's
libc/net/inet_net_pton.c (r1.13) implementation of inet_net_pton_ipv6().
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libc/net/inet_net_pton.c?annotate=1.13
The OpenBSD implementation was adapted to glibc as following:
1) Use strncpy() instead of strlcpy()
2) Use strtol() instead of strtonum()
3) Updated comments
I've tested the changeset on Debian Bookworm.
Kind regards,
Job
Signed-off-by: Job Snijders <job@fastly.com>
Comments
* Job Snijders via Libc-alpha:
> + strncpy(buf, src, sizeof(buf) - 1);
> + buf[sizeof(buf) - 1] = '\0';
> +
> + sep = strchr(buf, '/');
> + if (sep != NULL)
> + *sep++ = '\0';
> +
> + if (inet_pton(AF_INET6, buf, &in6) != 1) {
> + __set_errno (ENOENT);
> + return (-1);
> + }
Thanks for the patch.
We have __inet_pton_length for internal use. You can use it to avoid
the copy. Would you be interested in reworking your patch based on it?
Florian
Dear all,
On 12/22/22 18:54, Job Snijders via Libc-alpha wrote:
> Dear all,
>
> This changeset adds support to inet_net_pton() to convert IPv6 network
> numbers (IPv6 prefixes with CIDR notation) from presentation format to
> network format.
>
> The starting point of this changeset was OpenBSD's
> libc/net/inet_net_pton.c (r1.13) implementation of inet_net_pton_ipv6().
> https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libc/net/inet_net_pton.c?annotate=1.13
> The OpenBSD implementation was adapted to glibc as following:
>
> 1) Use strncpy() instead of strlcpy()
Would someone please add a function to glibc that truncates a string, while
still producing a string (as opposed to a null-padded fixed-width character
sequence)?
Here goes an extract of the yet-unreleased strncpy(3) manual page from the Linux
man-pages master branch:
DESCRIPTION
These functions copy the string pointed to by src into a null‐padded
character sequence at the fixed‐width buffer pointed to by dst. If the
destination buffer, limited by its size, isn’t large enough to hold the
copy, the resulting character sequence is truncated. For the differ‐
ence between the two functions, see RETURN VALUE.
An implementation of these functions might be:
char *
stpncpy(char *restrict dst, const char *restrict src, size_t sz)
{
bzero(dst, sz);
return mempcpy(dst, src, strnlen(src, sz));
}
char *
strncpy(char *restrict dst, const char *restrict src, size_t sz)
{
stpncpy(dst, src, sz);
return dst;
}
[...]
CAVEATS
The name of these functions is confusing. These functions produce a
null‐padded character sequence, not a string (see string_copying(7)).
It’s impossible to distinguish truncation by the result of the call,
from a character sequence that just fits the destination buffer; trun‐
cation should be detected by comparing the length of the input string
with the size of the destination buffer.
I'll be releasing the a new man-pages version very soon (a week at most), so
that this page and also the new string_copying(7) overview are widely available.
Cheers,
Alex
> 2) Use strtol() instead of strtonum()
> 3) Updated comments
>
> I've tested the changeset on Debian Bookworm.
>
> Kind regards,
>
> Job
>
>
> Signed-off-by: Job Snijders <job@fastly.com>
>
> diff --git resolv/inet_net_pton.c resolv/inet_net_pton.c
> index aab9b7b582..163e76e1a5 100644
> --- resolv/inet_net_pton.c
> +++ resolv/inet_net_pton.c
> @@ -1,4 +1,6 @@
> /*
> + * Copyright (c) 2022 Job Snijders <job@fastly.com>
> + * Copyright (c) 2012 by Gilles Chehade <gilles@openbsd.org>
> * Copyright (c) 1996,1999 by Internet Software Consortium.
> *
> * Permission to use, copy, modify, and distribute this software for any
> @@ -35,13 +37,16 @@
>
> static int inet_net_pton_ipv4 (const char *src, u_char *dst,
> size_t size) __THROW;
> +static int inet_net_pton_ipv6 (const char *src, u_char *dst,
> + size_t size) __THROW;
>
> /*
> - * static int
> + * int
> * inet_net_pton(af, src, dst, size)
> - * convert network number from presentation to network format.
> - * accepts hex octets, hex strings, decimal octets, and /CIDR.
> - * "size" is in bytes and describes "dst".
> + * Convert network number from presentation format to network format.
> + * If "af" is set to AF_INET, accept various formats like hex octets,
> + * hex strings, or decimal octets. If "af" is set to AF_INET6, accept
> + * IPv6 addresses. "size" is in bytes and describes "dst".
> * return:
> * number of bits, either imputed classfully or specified with /CIDR,
> * or -1 if some failure occurred (check errno). ENOENT means it was
> @@ -55,6 +60,8 @@ inet_net_pton (int af, const char *src, void *dst, size_t size)
> switch (af) {
> case AF_INET:
> return (inet_net_pton_ipv4(src, dst, size));
> + case AF_INET6:
> + return (inet_net_pton_ipv6(src, dst, size));
> default:
> __set_errno (EAFNOSUPPORT);
> return (-1);
> @@ -196,3 +203,64 @@ inet_net_pton_ipv4 (const char *src, u_char *dst, size_t size)
> __set_errno (EMSGSIZE);
> return (-1);
> }
> +
> +
> +/*
> + * Convert an IPv6 prefix from presentation format to network format.
> + * Return the number of bits specified, or -1 as error (check errno).
> + */
> +static int
> +inet_net_pton_ipv6 (const char *src, u_char *dst, size_t size)
> +{
> + struct in6_addr in6;
> + int bits;
> + long lbits;
> + size_t bytes;
> + char buf[INET6_ADDRSTRLEN + sizeof("/128")];
> + char *ep, *sep;
> +
> + strncpy(buf, src, sizeof(buf) - 1);
The -1 above is unnecessary.
> + buf[sizeof(buf) - 1] = '\0';
> +
> + sep = strchr(buf, '/');
> + if (sep != NULL)
> + *sep++ = '\0';
> +
> + if (inet_pton(AF_INET6, buf, &in6) != 1) {
> + __set_errno (ENOENT);
> + return (-1);
> + }
> +
> + if (sep == NULL) {
> + bits = 128;
> + goto out;
> + }
> +
> + if (sep[0] == '\0' || !isascii(sep[0]) || !isdigit(sep[0])) {
> + __set_errno (ENOENT);
> + return (-1);
> + }
> +
> + errno = 0;
> + lbits = strtol(sep, &ep, 10);
> + if (sep[0] == '\0' || *ep != '\0') {
> + __set_errno (ENOENT);
> + return (-1);
> + }
> + if ((errno == ERANGE && (lbits == LONG_MAX || lbits == LONG_MIN))
> + || (lbits > 128 || lbits < 0)) {
> + __set_errno (EMSGSIZE);
> + return (-1);
> + }
> + bits = lbits;
> +
> + out:
> + bytes = (bits + 7) / 8;
> + if (bytes > size) {
> + __set_errno (EMSGSIZE);
> + return (-1);
> + }
> +
> + memcpy(dst, &in6.s6_addr, bytes);
> + return (bits);
> +}
--
<http://www.alejandro-colomar.es/>
On 12/22/22 19:28, Alejandro Colomar wrote:>> 1) Use strncpy() instead of strlcpy()
>
> Would someone please add a function to glibc that truncates a string, while
> still producing a string (as opposed to a null-padded fixed-width character
> sequence)?
>
> Here goes an extract of the yet-unreleased strncpy(3) manual page from the Linux
> man-pages master branch:
>
>
> DESCRIPTION
> These functions copy the string pointed to by src into a null‐padded
> character sequence at the fixed‐width buffer pointed to by dst. If the
> destination buffer, limited by its size, isn’t large enough to hold the
> copy, the resulting character sequence is truncated. For the differ‐
> ence between the two functions, see RETURN VALUE.
>
> An implementation of these functions might be:
>
> char *
> stpncpy(char *restrict dst, const char *restrict src, size_t sz)
> {
> bzero(dst, sz);
> return mempcpy(dst, src, strnlen(src, sz));
> }
>
> char *
> strncpy(char *restrict dst, const char *restrict src, size_t sz)
> {
> stpncpy(dst, src, sz);
> return dst;
> }
>
> [...]
>
> CAVEATS
> The name of these functions is confusing. These functions produce a
> null‐padded character sequence, not a string (see string_copying(7)).
>
> It’s impossible to distinguish truncation by the result of the call,
> from a character sequence that just fits the destination buffer; trun‐
> cation should be detected by comparing the length of the input string
> with the size of the destination buffer.
>
> I'll be releasing the a new man-pages version very soon (a week at most), so
> that this page and also the new string_copying(7) overview are widely available.
I released a moment ago. So, I'd suggest either adding strlcpy(3)&strlcat(3) to
glibc, or stpecpy(3) (defined here:
<http://www.alejandro-colomar.es/src/alx/alx/libstp.git/tree/src/stp/stpe/stpecpy.c>).
Or even both, since each of them serves a purpose: strlcpy(3)&strlcat(3) are
for simpler code where performance and truncation are not a concern, and
stpecpy(3) does the same but faster with just a few more bytes of code (and
detecting truncation is even simpler).
I'll send an actual patch for adding stpecpy(3), to discuss with some actual code.
Cheers,
Alex
--
<http://www.alejandro-colomar.es/>
> On 22 Dec 2022, at 20:25, Alejandro Colomar via Libc-alpha <libc-alpha@sourceware.org> wrote:
>
> On 12/22/22 19:28, Alejandro Colomar wrote:>> 1) Use strncpy() instead of strlcpy()
>> Would someone please add a function to glibc that truncates a string, while still producing a string (as opposed to a null-padded fixed-width character sequence)?
>> Here goes an extract of the yet-unreleased strncpy(3) manual page from the Linux man-pages master branch:
>> DESCRIPTION
>> These functions copy the string pointed to by src into a null‐padded
>> character sequence at the fixed‐width buffer pointed to by dst. If the
>> destination buffer, limited by its size, isn’t large enough to hold the
>> copy, the resulting character sequence is truncated. For the differ‐
>> ence between the two functions, see RETURN VALUE.
>> An implementation of these functions might be:
>> char *
>> stpncpy(char *restrict dst, const char *restrict src, size_t sz)
>> {
>> bzero(dst, sz);
>> return mempcpy(dst, src, strnlen(src, sz));
>> }
>> char *
>> strncpy(char *restrict dst, const char *restrict src, size_t sz)
>> {
>> stpncpy(dst, src, sz);
>> return dst;
>> }
>> [...]
>> CAVEATS
>> The name of these functions is confusing. These functions produce a
>> null‐padded character sequence, not a string (see string_copying(7)).
>> It’s impossible to distinguish truncation by the result of the call,
>> from a character sequence that just fits the destination buffer; trun‐
>> cation should be detected by comparing the length of the input string
>> with the size of the destination buffer.
>> I'll be releasing the a new man-pages version very soon (a week at most), so that this page and also the new string_copying(7) overview are widely available.
>
> I released a moment ago. So, I'd suggest either adding strlcpy(3)&strlcat(3) to glibc, or stpecpy(3) (defined here: <http://www.alejandro-colomar.es/src/alx/alx/libstp.git/tree/src/stp/stpe/stpecpy.c>). Or even both, since each of them serves a purpose: strlcpy(3)&strlcat(3) are for simpler code where performance and truncation are not a concern, and stpecpy(3) does the same but faster with just a few more bytes of code (and detecting truncation is even simpler).
>
strlcpy and strlcat is in POSIX next (https://www.austingroupbugs.net/view.php?id=986) and will be in glibc
in due course, I believe.
See https://sourceware.org/bugzilla/show_bug.cgi?id=178. Florian sent a patch a few months ago
but I don't think anything happened with it yet (https://patchwork.sourceware.org/project/glibc/patch/87fsjp7rqz.fsf@oldenburg.str.redhat.com/).
I'll update a bug with this new information, as well.
Best,
sam
> On 23 Dec 2022, at 06:55, Sam James via Libc-alpha <libc-alpha@sourceware.org> wrote:
> strlcpy and strlcat is in POSIX next (https://www.austingroupbugs.net/view.php?id=986) and will be in glibc
> in due course, I believe.
>
> See https://sourceware.org/bugzilla/show_bug.cgi?id=178. Florian sent a patch a few months ago
> but I don't think anything happened with it yet (https://patchwork.sourceware.org/project/glibc/patch/87fsjp7rqz.fsf@oldenburg.str.redhat.com/).
>
Ah, I didn't read over the discussion again as I thought I'd remembered it all,
but since then, Paul's objection bug w/ austingroup has been closed, so I don't see
a reason not to move forward.
Hey Sam!
On 12/23/22 08:00, Sam James wrote:
>
>
>> On 23 Dec 2022, at 06:55, Sam James via Libc-alpha <libc-alpha@sourceware.org> wrote:
>
>> strlcpy and strlcat is in POSIX next (https://www.austingroupbugs.net/view.php?id=986) and will be in glibc
>> in due course, I believe.
>>
>> See https://sourceware.org/bugzilla/show_bug.cgi?id=178. Florian sent a patch a few months ago
>> but I don't think anything happened with it yet (https://patchwork.sourceware.org/project/glibc/patch/87fsjp7rqz.fsf@oldenburg.str.redhat.com/).
>>
> Ah, I didn't read over the discussion again as I thought I'd remembered it all,
> but since then, Paul's objection bug w/ austingroup has been closed, so I don't see
> a reason not to move forward.
Ahh, good then. BTW, could you please link to Paul's objection? I couldn't
find it. Anyway, I'll CC him.
I'll reply on the other thread, since I still think we need the other function.
Cheers,
Alex
P.S.: I think you may have libc-alpha as 'Zack Weinberg via Libc-alpha' on you
address book? Or maybe it's my thunderbird? I think it's not me.
--
<http://www.alejandro-colomar.es/>
Oops, I accidentally CCd the wrong Paul. I intended to CC Eggert :P Added.
On 12/23/22 12:42, Alejandro Colomar wrote:
> Hey Sam!
>
> On 12/23/22 08:00, Sam James wrote:
>>
>>
>>> On 23 Dec 2022, at 06:55, Sam James via Libc-alpha
>>> <libc-alpha@sourceware.org> wrote:
>>
>>> strlcpy and strlcat is in POSIX next
>>> (https://www.austingroupbugs.net/view.php?id=986) and will be in glibc
>>> in due course, I believe.
>>>
>>> See https://sourceware.org/bugzilla/show_bug.cgi?id=178. Florian sent a patch
>>> a few months ago
>>> but I don't think anything happened with it yet
>>> (https://patchwork.sourceware.org/project/glibc/patch/87fsjp7rqz.fsf@oldenburg.str.redhat.com/).
>>>
>> Ah, I didn't read over the discussion again as I thought I'd remembered it all,
>> but since then, Paul's objection bug w/ austingroup has been closed, so I
>> don't see
>> a reason not to move forward.
>
> Ahh, good then. BTW, could you please link to Paul's objection? I couldn't
> find it. Anyway, I'll CC him.
>
> I'll reply on the other thread, since I still think we need the other function.
>
> Cheers,
>
> Alex
>
> P.S.: I think you may have libc-alpha as 'Zack Weinberg via Libc-alpha' on you
> address book? Or maybe it's my thunderbird? I think it's not me.
>
>
--
<http://www.alejandro-colomar.es/>
> On 23 Dec 2022, at 11:42, Alejandro Colomar <alx.manpages@gmail.com> wrote:
>
> Hey Sam!
>
> On 12/23/22 08:00, Sam James wrote:
>>> On 23 Dec 2022, at 06:55, Sam James via Libc-alpha <libc-alpha@sourceware.org> wrote:
>>> strlcpy and strlcat is in POSIX next (https://www.austingroupbugs.net/view.php?id=986) and will be in glibc
>>> in due course, I believe.
>>>
>>> See https://sourceware.org/bugzilla/show_bug.cgi?id=178. Florian sent a patch a few months ago
>>> but I don't think anything happened with it yet (https://patchwork.sourceware.org/project/glibc/patch/87fsjp7rqz.fsf@oldenburg.str.redhat.com/).
>>>
>> Ah, I didn't read over the discussion again as I thought I'd remembered it all,
>> but since then, Paul's objection bug w/ austingroup has been closed, so I don't see
>> a reason not to move forward.
>
> Ahh, good then. BTW, could you please link to Paul's objection? I couldn't find it. Anyway, I'll CC him.
https://austingroupbugs.net/view.php?id=1591
>
> I'll reply on the other thread, since I still think we need the other function.
>
> Cheers,
>
> Alex
>
> P.S.: I think you may have libc-alpha as 'Zack Weinberg via Libc-alpha' on you address book? Or maybe it's my thunderbird? I think it's not me.
>
Oops! I'll fix. It was automatic.
@@ -1,4 +1,6 @@
/*
+ * Copyright (c) 2022 Job Snijders <job@fastly.com>
+ * Copyright (c) 2012 by Gilles Chehade <gilles@openbsd.org>
* Copyright (c) 1996,1999 by Internet Software Consortium.
*
* Permission to use, copy, modify, and distribute this software for any
@@ -35,13 +37,16 @@
static int inet_net_pton_ipv4 (const char *src, u_char *dst,
size_t size) __THROW;
+static int inet_net_pton_ipv6 (const char *src, u_char *dst,
+ size_t size) __THROW;
/*
- * static int
+ * int
* inet_net_pton(af, src, dst, size)
- * convert network number from presentation to network format.
- * accepts hex octets, hex strings, decimal octets, and /CIDR.
- * "size" is in bytes and describes "dst".
+ * Convert network number from presentation format to network format.
+ * If "af" is set to AF_INET, accept various formats like hex octets,
+ * hex strings, or decimal octets. If "af" is set to AF_INET6, accept
+ * IPv6 addresses. "size" is in bytes and describes "dst".
* return:
* number of bits, either imputed classfully or specified with /CIDR,
* or -1 if some failure occurred (check errno). ENOENT means it was
@@ -55,6 +60,8 @@ inet_net_pton (int af, const char *src, void *dst, size_t size)
switch (af) {
case AF_INET:
return (inet_net_pton_ipv4(src, dst, size));
+ case AF_INET6:
+ return (inet_net_pton_ipv6(src, dst, size));
default:
__set_errno (EAFNOSUPPORT);
return (-1);
@@ -196,3 +203,64 @@ inet_net_pton_ipv4 (const char *src, u_char *dst, size_t size)
__set_errno (EMSGSIZE);
return (-1);
}
+
+
+/*
+ * Convert an IPv6 prefix from presentation format to network format.
+ * Return the number of bits specified, or -1 as error (check errno).
+ */
+static int
+inet_net_pton_ipv6 (const char *src, u_char *dst, size_t size)
+{
+ struct in6_addr in6;
+ int bits;
+ long lbits;
+ size_t bytes;
+ char buf[INET6_ADDRSTRLEN + sizeof("/128")];
+ char *ep, *sep;
+
+ strncpy(buf, src, sizeof(buf) - 1);
+ buf[sizeof(buf) - 1] = '\0';
+
+ sep = strchr(buf, '/');
+ if (sep != NULL)
+ *sep++ = '\0';
+
+ if (inet_pton(AF_INET6, buf, &in6) != 1) {
+ __set_errno (ENOENT);
+ return (-1);
+ }
+
+ if (sep == NULL) {
+ bits = 128;
+ goto out;
+ }
+
+ if (sep[0] == '\0' || !isascii(sep[0]) || !isdigit(sep[0])) {
+ __set_errno (ENOENT);
+ return (-1);
+ }
+
+ errno = 0;
+ lbits = strtol(sep, &ep, 10);
+ if (sep[0] == '\0' || *ep != '\0') {
+ __set_errno (ENOENT);
+ return (-1);
+ }
+ if ((errno == ERANGE && (lbits == LONG_MAX || lbits == LONG_MIN))
+ || (lbits > 128 || lbits < 0)) {
+ __set_errno (EMSGSIZE);
+ return (-1);
+ }
+ bits = lbits;
+
+ out:
+ bytes = (bits + 7) / 8;
+ if (bytes > size) {
+ __set_errno (EMSGSIZE);
+ return (-1);
+ }
+
+ memcpy(dst, &in6.s6_addr, bytes);
+ return (bits);
+}