Linux support for java.security.jgss "nativeccache" functionality

[Hall, Nick]

Hi,

The current OpenJDK code has "native" ccache support for both Windows/Mac, allowing native Kerberos credential acquisition on those platforms via the usual system library calls rather than the pure Java code.  It does not support Linux, meaning that only file based ccaches are supported on that platform.  I couldn't find any other similar bug reports/fixes/submissions, so have developed a patch that I'd like to contribute to improve this support (for full disclosure, this is a corporate submission approved by my employer, and the OCA has been appropriately signed; this is my first time contributing to the OpenJDK).

The motivation for doing this is that the Linux Kerberos / GSS-API system libraries support more than just file-based Kerberos credential caches - in particular, we're interested in supporting KCM, which is a standard protocol for acquiring credentials via a service based cache - there are two existing implementations in Heimdal Kerberos and the RedHat SSSD.  As it stands now, supporting KCM for Java processes means running them inside a "kstart" shell which copies a KCM cache to a file ccache for the process to use initially.  This is an unergonomic approach that we would like to avoid, as it's a source of errors in our environment.

The patch generalizes the Mac support to include Linux - the C code (ref src/java.security.jgss/macosx/native/libosxkrb5/nativeccache.c) required here is identical to the Mac version other than the header files (and includes a bug fix to avoid a segfault caused by a null pointer deref, which I suspect is a dormant bug on MacOSX too).  The only other required changes are in the Java code which loads the relevant libraries and calls them, in both cases these are just changes to an existing conditional.

I'd be interested in feedback, and had some questions about how to approach the shared nature of the code between MacOSX and Linux based on the options I've tried here:


  *   Option 1: duplicate the code, fix the headers and build a separate Linux shared object.  This has the disadvantage of a lot of duplicated code, but keeps each platform's libraries separate/distinct.
  *   Option 2: build a common shared object on both MacOSX and Linux for the nativeccache functionality, using pre-processor directives to select the correct set of header files for each platform.  This has the advantage of a smaller patch (lines of code), but introduces a (no-op) change on MacOSX as a result.  MacOSX has one additional source file (SCDynamicStoreConfig) compiled into the library that Linux does not have.

The draft code for option 2 can be found at https://github.com/nrhall/jdk/commit/7b57a48afff77ef80dbb6cd947bd0d0581c439c1 (note that the GH Actions jobs currently fail on Linux because the runner needs to have at least libkrb5-dev installed, and that changes to autoconf/dependencies will be needed to ensure these libs/headers are installed at compile time at least - with some careful handling at library load time to handle the error if not).

If there's interest in pursuing this, I'd be happy to raise a PR  - please let me know if there are any questions!

Thanks,
Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20250131/f25ea7eb/attachment.htm>