[
https://issues.apache.org/jira/browse/HADOOP-18972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18080651#comment-18080651
]
ASF GitHub Bot commented on HADOOP-18972:
-----------------------------------------
charlesconnell opened a new pull request, #6272:
URL: https://github.com/apache/hadoop/pull/6272
### Description of PR
When `SaslDataTransferServer` or `SaslDataTranferClient` want to get a SASL
properties map to do a handshake, they call
`SaslPropertiesResolver#getServerProperties()` or
`SaslPropertiesResolver#getClientProperties()`, and they get back a
`Map<String, String>`. Every call gets the same Map object back, and then the
callers sometimes call
[put()](https://github.com/apache/hadoop/blob/rel/release-3.3.6/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/protocol/datatransfer/sasl/SaslDataTransferServer.java#L385)
on it. This means that future users of `SaslPropertiesResolver` get back the
wrong information.
In this PR, `SaslPropretiesResolver` gives out copies of its internal map,
so that users can safety modify them.
### How was this patch tested?
My employer has [effectively the same
patch](https://github.com/HubSpot/hadoop/commit/6761522efd5f6ac6117ee151c44edb7d97ca0031)
already committed to our fork of Hadoop 3.3.1. We are running this in
production, and have found that this patch fixes the problem we were
experiencing, described in the JIRA ticket.
### For code changes:
- [x] Does the title or this PR starts 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?
- [ ] 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?
> Bug in SaslPropertiesResolver allows mutation of internal state
> ---------------------------------------------------------------
>
> Key: HADOOP-18972
> URL: https://issues.apache.org/jira/browse/HADOOP-18972
> Project: Hadoop Common
> Issue Type: Bug
> Reporter: Charles Connell
> Priority: Minor
> Labels: pull-request-available
>
> When {{SaslDataTransferServer}} or {{SaslDataTranferClient}} want to get a
> SASL properties map to do a handshake, they call
> {{SaslPropertiesResolver#getServerProperties()}} or
> {{SaslPropertiesResolver#getClientProperties()}}, and they get back a
> {{Map<String, String>}}. Every call gets the same {{Map}} object back, and
> then the callers sometimes call
> [put()|https://github.com/apache/hadoop/blob/rel/release-3.3.6/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/protocol/datatransfer/sasl/SaslDataTransferServer.java#L385]
> on it. This means that future users of {{SaslPropertiesResolver}} get back
> the wrong information.
> I propose that {{SaslPropertiesResolver}} should pass a copy of its internal
> map, so that users can safety modify them.
> I discovered this problem in my company's testing environment as we began to
> enable {{dfs.data.transfer.protection}} on our DataNodes, while our NameNodes
> were using {{IngressPortBasedResolver}} to give out block tokens with
> different QOPs depending on the port used. Then our HDFS client applications
> became unable to read or write to HDFS because they could not find a QOP in
> common with the DataNodes during SASL handshake. With multiple threads
> executing SASL handshakes at the same time, the properties map used in
> {{SaslDataTransferServer}} in a DataNode could be clobbered during usage,
> since the same map was used by all threads. Also, future clients that do not
> have a QOP embedded in their block tokens would connect to a server with the
> wrong SASL properties map. I think that one or both of these issues explains
> the problem that I saw. I eliminated this unsafety and saw the problem go
> away.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
