8349546: Linux support for Kerberos "nativeccache" functionality #28075

nrhall · 2025-10-30T22:04:52Z

Purpose

This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX.

Rationale

Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches). There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types), This support already exists on MacOSX and Windows.

The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively. This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature).

Additionally this PR fixes a bug that's existed for a while (see L585-588 in nativeccache.c) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses). It also fixes a (non problem) typo in the variable name in a function prototype.

Implementation Detail

Note that there were multiple possible ways of doing this:

Duplicate the MacOSX nativeccache.c, edit lightly for Linux and build a new library on Linux only (liblinuxkrb5), leaving MacOSX largely unchanged, but at the expense of this code duplication.
Create a new shared library used on both platforms with conditional compilation to manage the differences. This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect.
Create a shared nativeccache.c (using EXTRA_SRC in the build) and build separate MacOSX/Linux libraries. This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux.

I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result. Hopefully the additional jtreg test is sufficient to compensate for this.

Interested to hear if anyone else has any suggestions for better ideas!

Notes

It wasn't clear to me what I should do with copyright headers/updating dates in headers. I've added similar boilerplate headers seen in other files to some of the new files, but please let me know what the usual form is here.

Progress

Change must be properly reviewed (1 review required, with at least 1 Reviewer)
Change must not contain extraneous whitespace
Commit message must refer to an issue

Issue

JDK-8349546: Linux support for Kerberos "nativeccache" functionality (Enhancement - P4)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/28075/head:pull/28075
$ git checkout pull/28075

Update a local copy of the PR:
$ git checkout pull/28075
$ git pull https://git.openjdk.org/jdk.git pull/28075/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 28075

View PR using the GUI difftool:
$ git pr show -t 28075

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/28075.diff

Using Webrev

Link to Webrev Comment

bridgekeeper · 2025-10-30T22:06:38Z

👋 Welcome back nrhall! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2025-10-30T22:07:18Z

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

openjdk · 2025-10-30T22:08:08Z

@nrhall The following labels will be automatically applied to this pull request:

build
security

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command.

mlbridge · 2025-10-30T22:39:11Z

Webrevs

erikj79 · 2025-10-30T22:55:34Z

Is there a particular reason for build.sh in the tests or are you just not familiar with how native test code gets automatically compiled by the makefiles based on file naming conventions? In short, any file lib*.c[pp] will get compiled into a native library (and exe*.c[pp] into an executable). You can define any special flags or platform include/exclude in make/test/JtregNativeJdk.gmk.

nrhall · 2025-10-30T23:02:30Z

Is there a particular reason for build.sh in the tests or are you just not familiar with how native test code gets automatically compiled by the makefiles based on file naming conventions? In short, any file lib*.c[pp] will get compiled into a native library (and exe*.c[pp] into an executable). You can define any special flags or platform include/exclude in make/test/JtregNativeJdk.gmk.

Definitely the unfamiliar bit, although the build.sh was useful for doing some quick test runs. Is there an example you could point me at - I'd be happy to fix that.

Edit: found some examples - fix incoming.

nrhall · 2025-10-30T23:33:20Z

@erikj79 I've had a go at the suggested changes - hope that's more what you were looking for?

…is not installed

erikj79 · 2025-10-31T14:13:52Z

make/autoconf/libraries.m4

+  if test "x$OPENJDK_TARGET_OS" = xlinux -o "x$OPENJDK_TARGET_OS" = xmacosx; then
+    NEEDS_LIB_KRB5=true


My understanding is that this external dependency is only needed on Linux. The resulting variable even has linux in the name.

erikj79 · 2025-10-31T14:17:24Z

make/autoconf/lib-krb5.m4

+  AC_ARG_WITH(krb5, [AS_HELP_STRING([--with-krb5],
+      [enable krb5 support (default=yes), or "no" to disable])])


If this is an optional dependency, this option should take three values: yes/no/auto. The default should be "auto".

yes: Fail if the library cannot be found

no: Disable the feature

auto: Look for the library and enable if found, otherwise disable

Also the help text should make it clear that this is Linux only.

For other library dependency options, the with- option can also be used to point to the location of the installation, usually combined with individual --with--include and --with--lib. I think something like this might be good to support, but I'm not familiar with this lib and possible installation options.

erikj79 · 2025-10-31T14:22:15Z

make/autoconf/lib-krb5.m4

+    ENABLE_LIBLINUXKRB5=false
+  else
+    # First try pkg-config (most modern approach)
+    AC_PATH_TOOL([PKG_CONFIG], [pkg-config], [no])


PKG_CONFIG should already be setup in pkg.m4.

erikj79 · 2025-10-31T14:27:56Z

make/autoconf/lib-krb5.m4

+      ENABLE_LIBLINUXKRB5=true
+    else
+      # Fallback: try krb5-config
+      AC_PATH_TOOL([KRB5CONF], [krb5-config], [no])


We have our own internal macro UTIL_LOOKUP_PROGS that is preferred over the AC variants.

erikj79 · 2025-10-31T14:30:47Z

make/autoconf/lib-krb5.m4

+  if test "x${with_krb5}" = xno; then
+    AC_MSG_NOTICE([krb5 explicitly disabled])
+    KRB5_DISABLED=yes
+  elif test "x$NEEDS_LIB_KRB5" = xfalse; then


Since this is an optional dependency, perhaps use a different variable name?

erikj79 · 2025-10-31T14:32:41Z

make/autoconf/spec.gmk.template

 ALSA_CFLAGS := @ALSA_CFLAGS@
+KRB5_LIBS := @KRB5_LIBS@
+KRB5_CFLAGS := @KRB5_CFLAGS@
+ENABLE_LIBLINUXKRB5 := @ENABLE_LIBLINUXKRB5@


A better name would perhaps be ENABLE_LIBKRB5_LINUX or ENABLE_LINUX_LIBKRB5, maybe even just ENABLE_LIBKRB5?

erikj79 · 2025-10-31T17:37:49Z

make/autoconf/lib-krb5.m4

+    AC_PATH_TOOL([PKG_CONFIG], [pkg-config], [no])
+    use_pkgconfig_for_krb5=no
+
+    if test "x$PKG_CONFIG" != "xno"; then


If SYSROOT is set, we should not try to use pkg-config or any other similar tool, as that would try to pick it up from the build host rather than the target sysroot. See how other external dependencies handle this.

erikj79 · 2025-10-31T17:39:10Z

make/test/JtregNativeJdk.gmk

+  ifeq ($(call isTargetOs, macosx), true)
+    # On macOS, disable deprecation warnings for krb5 API
+    BUILD_JDK_JTREG_LIBRARIES_CFLAGS_libNativeCredentialCacheHelper += -Wno-deprecated-declarations
+  endif


Isn't this enabled and should be tested on macos regardless of ENABLE_LIBLINUXKRB5 as support was there already?

nrhall · 2025-10-31T22:21:46Z

Thanks for all the help and pointers @erikj79 - I've pushed a commit to (hopefully) address all of your comments!

erikj79

From a build point of view this is definitely starting to look better. I would like to get input from a reviewer in the component team at this point to comment on the validity of the change before I spend more time reviewing the build aspects.

make/autoconf/lib-krb5.m4

erikj79 · 2025-11-03T13:47:48Z

make/modules/java.security.jgss/Lib.gmk

  endif
+
+  ifeq ($(call isTargetOs, linux), true)
+    ifeq ($(ENABLE_LIBLINUXKRB5), true)


Suggested change

ifeq ($(ENABLE_LIBLINUXKRB5), true)

ifeq ($(ENABLE_LIBKRB5_LINUX), true)

erikj79 · 2025-11-03T14:11:06Z

make/autoconf/lib-krb5.m4

+        fi
+        AC_MSG_RESULT([$KRB5_FOUND])
+      else
+        PKG_CHECK_MODULES(KRB5, krb5, [KRB5_FOUND=yes], [KRB5_FOUND=no])


In lib-freetype.m4 we first check if PKG_CONFIG has a value before trying to use it. We also print a result because it seems PKG_CHECK_MODULES is quiet. I tried your patch here and configure doesn't produce any output in this case, so I think we should print something.

nrhall · 2025-11-03T18:45:16Z

Thanks for these @erikj79, no idea how I managed to miss at least one of those...! All addressed in latest commit.

Add support for native Kerberos credential acquisition on Linux

c0204db

openjdk bot added security [email protected] build [email protected] labels Oct 30, 2025

nrhall changed the title ~~8349546: Linux support for Kerberos "nativeccache” functionality~~ JDK-8349546: Linux support for Kerberos "nativeccache” functionality Oct 30, 2025

nrhall changed the title ~~JDK-8349546: Linux support for Kerberos "nativeccache” functionality~~ 8349546: Linux support for Kerberos "nativeccache” functionality Oct 30, 2025

nrhall changed the title ~~8349546: Linux support for Kerberos "nativeccache” functionality~~ 8349546: Linux support for Kerberos "nativeccache" functionality Oct 30, 2025

Fix permissions on build.sh

2e6cd02

openjdk bot added the rfr Pull request is ready for review label Oct 30, 2025

Tidy up comments/docs

307c3f2

nrhall added 2 commits October 30, 2025 19:23

eliminate build.sh in favour of jtreg primitives

5106d31

more comment fixes

33407d4

nrhall added 3 commits October 30, 2025 20:00

Add specific MacOS jtreg compiler flags to fix deprecation warnings

1a28cee

Add missing .h file to PR

5cad1e4

Fixes to ensure that the jtreg test is not built or executed if krb5 …

bc904b0

…is not installed

erikj79 reviewed Oct 31, 2025

View reviewed changes

Attend to @erikj79's code review comments

3ea9793

nrhall added 2 commits October 31, 2025 18:39

Minor variable/function name and comment clean-ups

d58d417

Minor doc/comment clean-ups

47968fe

erikj79 reviewed Nov 3, 2025

View reviewed changes

Address second set of @erikj79's build comments

8c8288a

nrhall requested a review from erikj79 November 3, 2025 18:47

		if test "x$OPENJDK_TARGET_OS" = xlinux -o "x$OPENJDK_TARGET_OS" = xmacosx; then
		NEEDS_LIB_KRB5=true

		AC_ARG_WITH(krb5, [AS_HELP_STRING([--with-krb5],
		[enable krb5 support (default=yes), or "no" to disable])])

	ifeq ($(ENABLE_LIBLINUXKRB5), true)
	ifeq ($(ENABLE_LIBKRB5_LINUX), true)

8349546: Linux support for Kerberos "nativeccache" functionality #28075

Are you sure you want to change the base?

8349546: Linux support for Kerberos "nativeccache" functionality #28075

Conversation

nrhall commented Oct 30, 2025 • edited by openjdk bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Progress

Issue

Reviewing

Uh oh!

bridgekeeper bot commented Oct 30, 2025

Uh oh!

openjdk bot commented Oct 30, 2025

Uh oh!

openjdk bot commented Oct 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mlbridge bot commented Oct 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Webrevs

Uh oh!

erikj79 commented Oct 30, 2025

Uh oh!

nrhall commented Oct 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

nrhall commented Oct 30, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nrhall commented Oct 31, 2025

Uh oh!

erikj79 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nrhall commented Nov 3, 2025

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

2 participants

nrhall commented Oct 30, 2025 •

edited by openjdk bot

Loading

openjdk bot commented Oct 30, 2025 •

edited

Loading

mlbridge bot commented Oct 30, 2025 •

edited

Loading

nrhall commented Oct 30, 2025 •

edited

Loading