On Tue, 18 Nov 2025 12:21:09 GMT, Nick Hall <[email protected]> wrote:
>> _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: >> >> 1) 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. >> >> 2) 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. >> >> 3) 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 >> compensat... > > Nick Hall has updated the pull request incrementally with one additional > commit since the last revision: > > Clean up jtreg run/compile directives, attend to other review comments Apologies for the slow response on this! > Maybe this is because the native library always exists on Windows and Mac, > therefore an UnsatisfiedLinkError is never thrown there. For Linux where it > could be missing, we should catch the error and gracefully fallback. Most likely this is how things got to the current state, yes. I think it might actually be advantageous in this case to build the JVM with krb5 compiled in, catch any link errors that happen because the runtime system doesn't have the Kerberos libraries and silently failback to the previous behaviour on Linux only, preserving the existing behaviour on Windows/Mac, where the library _should_ be there, and therefore a link error is a real failure. > After some offline discussion, I'm now OK with making this an optional > feature at build time. I think the only downside of this is that distributions might not build it in - meaning that people who want this would have to resort to compiling their own JVM (which some corporates, where this is most likely to be useful, might not allow - e.g. those that get their Java from RH/Canonical etc under a support agreement) or lobby their upstream provider, which isn't always particularly fruitful... ------------- PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3580434455
