[
https://issues.apache.org/jira/browse/HDFS-17668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Istvan Toth updated HDFS-17668:
-------------------------------
Description:
org.apache.hadoop.hdfs.protocol.datatransfer.sasl.DataTransferSaslUtil.checkSaslComplete(SaslParticipant,
Map<String, String>) used to throw an NPE when the SASL.getNegotiatedQop()
returned null. This was not ideal, but it erred on the side of caution, as it
kept mechanisms that did not set the negotiated QOP property at all from
working with Hadoop.
However, it was recently changed to skip the verification if the negotiated QOP
value is null.
This is a bug, as according to the docs, a null negotiated QOP value should be
treated as "auth"
[https://docs.oracle.com/en/java/javase/23/security/java-sasl-api-programming-and-deployment-guide1.html#GUID-762BDD49-6EE8-419C-A45E-540462CB192B]
The current checkSaslComplete() method will allow a null negotiated QOP value
when auth-conf QOP value was specified, which means that it the SASL
initialization will succeed, but all other Hadoop transfer methods will
(correctly) interpret the null QOP value as "auth" will not wrap the messages
with SASL, and use plain text, even though "auth-conf" was explicitly
requested. This is a bad thing.
This can happen if _dfs.encrypt.data.transfer_ is enabled, but the SASL
mechanism doesn't support QOP/encryption, and ignores the QOP value, and
returns null for the negotiated value.
In this case, Hadoop will negotiate encryption with the server, and treat the
null QOP value as the the requested QOP value.
was:
org.apache.hadoop.hdfs.protocol.datatransfer.sasl.DataTransferSaslUtil.checkSaslComplete(SaslParticipant,
Map<String, String>) used to throw an NPE when the SASL.getNegotiatedQop()
returned null. This was not ideal, but it erred on the side of caution, as it
kept mechanisms that did not set the negotiated QOP property at all from
working with Hadoop.
However, it was recently changed to skip the verification if the negotiated QOP
value is null.
This is a bug, as according to the docs, a null negotiated QOP value should be
treated as "auth"
[https://docs.oracle.com/en/java/javase/23/security/java-sasl-api-programming-and-deployment-guide1.html#GUID-762BDD49-6EE8-419C-A45E-540462CB192B]
The current checkSaslComplete() method will allow a null negotiated QOP value
when auth-conf QOP value was specified, which means that it the SASL
initialization will succeed, but all other Hadoop transfer methods will
(correctly) interpret the null QOP value as "auth" will not wrap the messages
with SASL, and use plain text, even though "auth-conf" was explicitly
requested. This is a bad thing.
This can happen if _dfs.encrypt.data.transfer_ is enabled, but the SASL
mechanism doesn't support QOP/encryption, and ignores the QOP value, and
returns null for the negotiated value.
In this case, Hadoop will negotiate encryption with the server, and will think
that encryption happens, but the encrpytion
> Treat null SASL negotiated QOP as auth in
> DataTransferSaslUtil#checkSaslComplete()
> ----------------------------------------------------------------------------------
>
> Key: HDFS-17668
> URL: https://issues.apache.org/jira/browse/HDFS-17668
> Project: Hadoop HDFS
> Issue Type: Bug
> Affects Versions: 3.5.0
> Reporter: Istvan Toth
> Priority: Major
> Labels: pull-request-available
>
> org.apache.hadoop.hdfs.protocol.datatransfer.sasl.DataTransferSaslUtil.checkSaslComplete(SaslParticipant,
> Map<String, String>) used to throw an NPE when the SASL.getNegotiatedQop()
> returned null. This was not ideal, but it erred on the side of caution, as it
> kept mechanisms that did not set the negotiated QOP property at all from
> working with Hadoop.
> However, it was recently changed to skip the verification if the negotiated
> QOP value is null.
> This is a bug, as according to the docs, a null negotiated QOP value should
> be treated as "auth"
> [https://docs.oracle.com/en/java/javase/23/security/java-sasl-api-programming-and-deployment-guide1.html#GUID-762BDD49-6EE8-419C-A45E-540462CB192B]
> The current checkSaslComplete() method will allow a null negotiated QOP value
> when auth-conf QOP value was specified, which means that it the SASL
> initialization will succeed, but all other Hadoop transfer methods will
> (correctly) interpret the null QOP value as "auth" will not wrap the messages
> with SASL, and use plain text, even though "auth-conf" was explicitly
> requested. This is a bad thing.
> This can happen if _dfs.encrypt.data.transfer_ is enabled, but the SASL
> mechanism doesn't support QOP/encryption, and ignores the QOP value, and
> returns null for the negotiated value.
> In this case, Hadoop will negotiate encryption with the server, and treat the
> null QOP value as the the requested QOP value.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
