netdev - Re: [PATCH 0/4] RFC: raw IPv6 address parsing in NFS client

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 19 May 2008 14:58:31 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	Chuck Lever <chuck.lever@...cle.com>
CC:	netdev@...r.kernel.org
Subject: Re: [PATCH 0/4] RFC: raw IPv6 address parsing in NFS client

Chuck Lever wrote:
> On May 18, 2008, at 10:13 PM, Jeff Garzik wrote:
>> Chuck Lever wrote:
>>> Hi-
>>> I'm interested in some review of the following four patches which add to
>>> the kernel's NFS client the ability to parse IPv6 addresses in 
>>> presentation
>>> format.
>>> Namely, it adds the following:
>>> 1.  If the user passes in an IPv6 address as the server name, the colons
>>>    in the address will confuse the logic that splits the device name
>>>    into a server hostname and an export path.   We'll use square 
>>> brackets
>>>    around IPv6 server addresses to "escape" the colons, as does Solaris.
>>> 2.  If the user passes in a link-local IPv6 address as the server name,
>>>    an interface index is also necessary.  We'll use the "%id" suffix on
>>>    the address to pass in the index, and plant that in the sockaddr's
>>>    sin6_scope_id field.
>>> In addition to the following patches in email, a git repo with these
>>> same patches already applied can be found here:
>>>     linux-nfs.org:exports/cel-2.6.git
>>> The basic questions:
>>> Are these reasonable conventions to follow?  Is the parsing logic 
>>> adequate?
>>> Is there anything I'm forgetting?
>>
>> I would take a look at the underlying components of glibc's 
>> getnameinfo(), which must parse IPv6 addresses according to POSIX 
>> specifications, IIRC.
>>
>> Comments:
>>
>> 1) bracket escaping seems reasonably common.  browsers and other apps 
>> sometimes use that convention too.
>>
>> 2) an interface name rather than index should be used
> 
> A few follow-up questions (for anyone, not just Jeff):
> 
> Should the kernel ignore any incoming scope/interface identifier unless 
> it verifies the address is link-local?
> 
> Do we really have to worry about the character set of incoming C strings?
> 
>        NI_IDN If  this  flag is used, then the name found in the
>               lookup process is converted from IDN format to the
>               locale’s encoding  if  necessary.  ASCII-only names
>               are not affected by the conversion, which makes this
>               flag usable in existing programs and environments.
> 
>        NI_IDN_ALLOW_UNASSIGNED, NI_IDN_USE_STD3_ASCII_RULES
>               Setting these flags will enable the IDNA_ALLOW_UNASSIGNED
>               (allow unassigned  Unicode  code  points)  and
>               IDNA_USE_STD3_ASCII_RULES (check output to make sure
>               it is a  STD3  conforming  host  name) flags
>               respectively to be used in the IDNA handling.
> 
> I would hope that this level of detail would be handled by utility 
> functions provided in net/core -- in6_pton, for example.

I don't think you need to worry about that?

getnameinfo() parses an IPv6 numeric address, and returns the name 
associated with it.  You only need the first half, the IPv6 address 
string parsing, correct?

If so, you don't need to care about the character sets of the returning 
lookup data.

I presume you are not adding an in-kernel DNS resolver, so this is all 
userspace details?

	Jeff




--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html