[jira] [Moved] (HDFS-18013) NFS gateway export rules do not support IPv6 clients or IPv6 entries

["Wei-Chiu Chuang (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/HDFS-18013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Wei-Chiu Chuang moved HADOOP-20029 to HDFS-18013:
-------------------------------------------------

        Key: HDFS-18013  (was: HADOOP-20029)
    Project: Hadoop HDFS  (was: Hadoop Common)

> NFS gateway export rules do not support IPv6 clients or IPv6 entries
> --------------------------------------------------------------------
>
>                 Key: HDFS-18013
>                 URL: https://issues.apache.org/jira/browse/HDFS-18013
>             Project: Hadoop HDFS
>          Issue Type: Bug
>            Reporter: Siyao Meng
>            Assignee: Siyao Meng
>            Priority: Major
>              Labels: ipv6
>
> {{NfsExports}}, which checks {{nfs.exports.allowed.hosts}} for the NFS gateway, only understands IPv4 ("only support IPv4 now"). On trunk:
> [NfsExports.java:69|https://github.com/apache/hadoop/blob/9ede2e95c6fb577d7ae8664833d5e151cbfc47c9/hadoop-common-project/hadoop-nfs/src/main/java/org/apache/hadoop/nfs/NfsExports.java#L69]
> *1. An IPv4 CIDR rule breaks requests from IPv6 clients.* {{CIDRMatch.isIncluded}} calls commons-net {{SubnetInfo.isInRange(address)}} with the client's address. For an IPv6 address commons-net 3.9.0 throws:
> {noformat}
> java.lang.IllegalArgumentException: Could not parse [2001:db8:0:0:0:0:0:10]
> {noformat}
> The exception is not caught in {{getAccessPrivilege}}, so it escapes the MOUNT and NFS3 request handlers ({{RpcProgramMountd.mnt}}, {{RpcProgramNfs3.checkAccessPrivilege}}) and the request gets no reply. This affects dual-stack gateways too, as soon as any IPv4 CIDR rule is configured. The default, {{* rw}}, is not affected.
> *2. IPv6 entries make the whole export list invalid.* An IPv6 address ({{2001:db8::10}}) or CIDR ({{2001:db8::/32}}) matches neither CIDR pattern, has no regex characters, and fails {{HOSTNAME_FORMAT}} because of the colons, so {{getMatch}} throws {{Invalid hostname provided}}. {{getInstance}} logs the error and returns null, and the gateway then denies every client, IPv4 included.
> *3. Exact and regex matches see the expanded form.* The client address comes from {{InetAddress.getHostAddress()}}, for example {{2001:db8:0:0:0:0:0:10}}, so an exact entry would need to use that spelling.
> I checked 1 and 2 with commons-net 3.9.0 (the version in {{hadoop-project/pom.xml}}) and the patterns copied from trunk's {{NfsExports}}.
> *Proposed fix:*
> * In {{CIDRMatch}}, return false for an IPv6 client instead of calling {{isInRange}}.
> * Accept IPv6 literals (bare or bracketed) as exact matches, compared by address, not by string.
> * Accept IPv6 CIDR entries with a prefix-bit match. HADOOP-19962 added the same kind of matching to {{MachineList}}, and the code could be shared.
> * Add tests for IPv4 and IPv6 clients against IPv4 and IPv6 rules.
> HDFS-17981 made the gateway's bind address configurable, so it can now listen on IPv6; this issue covers access control.
> POC: https://github.com/smengcl/hadoop/commit/0c318dd55ed0fae55bd8b6fed555f2063afb4225



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-help@hadoop.apache.org