[
https://issues.apache.org/jira/browse/HADOOP-20040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18133264#comment-18133264
]
ASF GitHub Bot commented on HADOOP-20040:
-----------------------------------------
smengcl opened a new pull request, #8880:
URL: https://github.com/apache/hadoop/pull/8880
Generated-by: Claude Code (Opus 5.5)
JIRA: https://issues.apache.org/jira/browse/HADOOP-20040
### Description of PR
With `hadoop.security.hostname.cache.expire-interval.seconds` > 0,
`SecurityUtil.CacheableHostResolver` (HADOOP-19447) hands the same
`InetAddress` instance to every caller resolving the same host, and
`NetUtils.createSocketAddrForHost` wraps it directly. For an IP literal
resolved by `StandardHostResolver` (the default, `use_ip=true`), the first
`getHostName()` call stores the reverse lookup result in that shared object, so
every later `getHostString()` for that IP in the JVM returns the PTR name
instead of the literal.
This change skips the cache for IP literals. Resolving a literal needs no
DNS lookup, so caching it saves nothing, and literals behave exactly as they
did with the cache off. Hostnames stay cached. Returning a copy via
`InetAddress.getByAddress(host, bytes)` was not used because it would make
`getHostName()` skip the reverse lookup, which changes behavior on its own.
### How was this patch tested?
`TestSecurityUtil` (29 tests) passes locally. The new
`testCacheableResolverDoesNotShareIpLiteral` covers `127.0.0.1`, `::1` and
`[::1]` and fails without the fix (`expected: not same but was:
<localhost/127.0.0.1>`). `testCacheableResolve` used `127.0.0.1` to check cache
hits, so it now uses `localhost` and checks the cache entry directly, since the
JDK returns the same object for a hostname from its own lookup cache.
### For code changes:
- [x] Does the title of this PR start with the corresponding JIRA issue id
(e.g. 'HADOOP-17799. Your PR title ...')?
- [ ] Object storage: Have the integration tests been executed and the
endpoint declared according to the connector-specific documentation? *Note:
Automated CI testing doesn't cover all cases so manual testing with cloud
storage is still required.*
- [ ] If adding new dependencies to the code, are these dependencies
licensed in a way that is compatible for inclusion under [ASF
2.0](http://www.apache.org/legal/resolved.html#category-a)?
- [ ] If applicable, have you updated the `LICENSE`, `LICENSE-binary`,
`NOTICE-binary` files?
### AI Tooling
If an AI tool was used:
- [x] The PR includes the phrase "Contains content generated by <tool>"
where <tool> is the name of the AI tool used.
- [x] My use of AI contributions follows the ASF legal policy
https://www.apache.org/legal/generative-tooling.html
Contains content generated by Claude Code.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
> SecurityUtil host resolver cache shares one mutable InetAddress per IP
> literal, leaking reverse lookups to other callers
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: HADOOP-20040
> URL: https://issues.apache.org/jira/browse/HADOOP-20040
> Project: Hadoop Common
> Issue Type: Bug
> Components: net, security
> Affects Versions: 3.5.0
> Reporter: Siyao Meng
> Assignee: Siyao Meng
> Priority: Major
>
> h3. Problem
> HADOOP-19447 added a cache to {{SecurityUtil.CacheableHostResolver}}, enabled
> when {{hadoop.security.hostname.cache.expire-interval.seconds}} > 0. The
> cache returns the same {{InetAddress}} instance to every caller resolving the
> same host string, and {{NetUtils.createSocketAddrForHost}} wraps that
> instance directly in a new {{InetSocketAddress}}.
> {{InetAddress}} is not immutable. For an IP literal resolved by
> {{StandardHostResolver}} (the default, since
> {{hadoop.security.token.service.use_ip}} defaults to true), the hostname is
> unset, and the first {{getHostName()}} call does a reverse lookup and stores
> the PTR name in the object. With the cache on, that one call changes the
> address seen by every later caller in the JVM:
> {code:java}
> InetSocketAddress a = NetUtils.createSocketAddr("10.0.0.5:8020");
> InetSocketAddress b = NetUtils.createSocketAddr("10.0.0.5:9870");
> b.getHostString(); // "10.0.0.5"
> a.getHostName(); // reverse lookup, e.g. "nn1.example.com"
> b.getHostString(); // now "nn1.example.com"
> NetUtils.createSocketAddr("10.0.0.5:50070").getHostString(); //
> "nn1.example.com"
> {code}
> Without the cache, each resolution returns a fresh object and
> {{getHostString()}} keeps returning the literal. So enabling the cache makes
> the host string of a configured IP address depend on unrelated earlier calls.
> The cache key is the host only, so addresses on different ports share the
> object too.
> Callers that trigger the reverse lookup include {{NetUtils.canonicalizeHost}}
> (via {{FileSystem}} URI canonicalization of {{hdfs://<ip>:<port>}}),
> {{NetUtils.getHostPortString}} and {{NameNode#loginAsNameNodeUser}}. Callers
> that read the host string include
> {{DatanodeHttpServer#getHostnameForSpnegoPrincipal}} (SPNEGO {{_HOST}}
> substitution), {{RBFMetrics}} router web URI, and
> {{InetSocketAddress#toString}} in logs. HDFS-18004 makes the NameNode RPC
> server bind to {{getHostString()}} so an IP literal is bound as given; with
> the cache on it silently falls back to binding the reverse lookup name.
> {{QualifiedHostResolver}} ({{use_ip=false}}) is not affected for literals,
> since it builds the address with {{InetAddress.getByAddress(host, bytes)}}
> and the hostname is already set.
> h3. Proposed fix
> Bypass the cache for IP literals in {{CacheableHostResolver#getByName}}.
> Resolving a literal needs no DNS lookup, so the cache saves nothing for it,
> and bypassing restores the exact pre-HADOOP-19447 behavior for literals.
> Hostnames stay cached; {{InetAddress.getByName(hostname)}} already sets the
> hostname, so {{getHostName()}} does not mutate those objects.
> Returning a copy via {{InetAddress.getByAddress(host, bytes)}} was considered
> and rejected: it would make {{getHostName()}} return the literal without the
> reverse lookup, which is a behavior change of its own.
> The existing {{TestSecurityUtil#testCacheableResolve}} used {{127.0.0.1}} to
> check cache hits, so it switches to {{localhost}} and checks expiry on the
> cache entry (the JDK returns the same object for a hostname from its own
> lookup cache). A new test checks that literals are not shared and keep their
> host string after {{getHostName()}}.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
