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

[Sean Mullan]

Hi Nick,

This proposal does sound like it would be useful, so I think we can 
start some more discussions about it. Once we go a bit further in the 
discussions and we decide it is worthwhile, we can open a JBS issue for 
tracking purposes. For starters, can you confirm that your company is 
"D. E. Shaw & Co., LP"?

--Sean

On 1/31/25 12:04 PM, Hall, Nick wrote:
> 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 <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
>