Hi Sean, Thanks for your response - I confirm that my company is D. E. Shaw & Co.
Let me know if I can provide any further information! Nick ________________________________ From: Sean Mullan <sean.mul...@oracle.com> Sent: Monday, February 3, 2025 11:03 pm To: Hall, Nick <nick.h...@deshaw.com>; security-dev@openjdk.org <security-dev@openjdk.org> Subject: Re: Linux support for java.security.jgss "nativeccache" functionality This message was sent by an external party. 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 >
