Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open Beginner friendly
  • Is something wrong?
#4,490 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@xinzhang-hello is already working on this.

Since Sep 28, 2026.

  • #4491 by @xinzhang-hello — open

Assessment

Difficulty
1/5
Estimated time
Under an hour
Newbie friendliness
88/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
hadoop, java
Domain
authentication, security

Research direction

Start by reading PlainSaslServerProvider.java and its initialize() method, then review how Java Security provider ordering affects Sasl.createSaslServer("PLAIN", ...). Done means Fluss's provider is registered ahead of Hadoop's provider so CLIENT:SASL authentication no longer fails with UnsupportedCallbackException.

Written by the indexing model from the issue text.

Description

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!
Dominant language
Java
Stars
2.2k
Forks
656
Avg merge
2d 14h
Merged PRs (30d)
108

Getting set up

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from apache/fluss

All issues in apache/fluss

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.