Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

[security] PlainSaslServerProvider conflicts with Hadoop SASL provider causing authentication failure

未关闭 适合新手
  • 哪里不对？
#4,490 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

@xinzhang-hello 已经在做这个了。

开始于 2026年9月28日。

  • #4491 来自 @xinzhang-hello —— 未关闭

评估

难度
1/5
预计耗时
1 小时以内
新手友好度
88/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
活跃
技术栈
hadoop, java
领域
authentication, security

调研方向

首先阅读 PlainSaslServerProvider.java 及其 initialize() 方法，然后检查 Java Security provider 的顺序如何影响 Sasl.createSaslServer("PLAIN", ...)。当 Fluss 的 provider 注册在 Hadoop 的 provider 之前，从而 CLIENT:SASL 认证不再因 UnsupportedCallbackException 失败时，即表示完成。

由索引模型根据 Issue 内容生成。

描述

Search before asking
  • I searched in the issues and found nothing similar.
Fluss version

main (development)

Please describe the bug 🐞

When running Fluss in an environment where Hadoop / HDFS dependencies are present on the classpath (for instance, when enabling HDFS remote log tiering or Paimon lake tiering), Hadoop's SaslRpcServer class registers its own SaslPlainServer.SecurityProvider into Java's Security providers.

Currently, Fluss initializes its SASL/PLAIN provider in PlainSaslServerProvider.java:

public static void initialize() {
    Security.addProvider(new PlainSaslServerProvider());
}

Security.addProvider() appends Fluss's PlainSaslServerProvider to the end of the provider list.

When a client attempts to connect to Fluss using SASL/PLAIN authentication (CLIENT:SASL), Java's Sasl.createSaslServer("PLAIN", ...) iterates through the registered providers and selects the first matching PLAIN provider, which is Hadoop's SaslPlainServer.SecurityProvider instead of Fluss's.

Because Hadoop's SASL PLAIN provider expects Hadoop-specific callbacks, it fails during authentication:

WARN org.apache.fluss.rpc.netty.server.NettyServerHandler - Connection is still in the authentication process. Unable to handle API key: 1012.
...
PLAIN auth failed: javax.security.auth.callback.UnsupportedCallbackException: Unrecognized Callback
    at org.apache.hadoop.security.SaslRpcServer$SaslPlainServer$SecurityProvider...

This causes all client SASL authentication attempts to fail.

Solution

In PlainSaslServerProvider.initialize(), use Security.insertProviderAt(new PlainSaslServerProvider(), 1); to register Fluss's PLAIN provider at the first position.

This guarantees that Fluss's own PlainSaslServer is always preferred over any third-party providers (such as Hadoop). This aligns with the implementation in Apache Kafka (org.apache.kafka.common.security.plain.PlainSaslServerProvider), which also uses Security.insertProviderAt(new PlainSaslServerProvider(), 1).

Are you willing to submit a PR?
  • I'm willing to submit a PR!
主要语言
Java
星标
2.2k
派生
656
平均合并
1 天 21 小时
30 天内合并 PR
127

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 有 Pull Request 模板
  • 没有贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

apache/fluss 的其他 Issue

查看 apache/fluss 的全部 Issue

相似的 Issue

更多 Java Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。