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 For what it's worth, here's how this looks using KCM on a host... ...with libkrb5 krb5loginmodule[0x3|main|Krb5LoginModule.java:647|2025-11-18 13:30:45.208]: Acquire TGT from Cache krb5loginmodule[0x3|main|Krb5LoginModule.java:678|2025-11-18 13:30:45.252]: Principal is [email protected] krb5loginmodule[0x3|main|Krb5LoginModule.java:1140|2025-11-18 13:30:45.272]: Commit Succeeded krb5loginmodule[0x3|main|Krb5LoginModule.java:1190|2025-11-18 13:30:45.273]: [Krb5LoginModule]: Entering logout krb5loginmodule[0x3|main|Krb5LoginModule.java:1218|2025-11-18 13:30:45.273]: [Krb5LoginModule]: logged out Subject ...without libkrb5: krb5loginmodule[0x3|main|Krb5LoginModule.java:647|2025-11-18 13:34:13.604]: Acquire TGT from Cache Exception in thread "main" java.lang.UnsatisfiedLinkError: /path/redacted/jdk/build/linux-x86_64-server-release/jdk/lib/liblinuxkrb5.so: libkrb5.so.3: cannot open shared object file: No such file or directory at java.base/jdk.internal.loader.NativeLibraries.load(Native Method) at java.base/jdk.internal.loader.NativeLibraries$NativeLibraryImpl.open(NativeLibraries.java:326) at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:187) at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:129) at java.base/jdk.internal.loader.NativeLibraries.findFromPaths(NativeLibraries.java:254) at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:239) at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2315) at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:822) at java.base/java.lang.System.loadLibrary(System.java:1685) at java.security.jgss/sun.security.krb5.Credentials.ensureLoaded(Credentials.java:535) at java.security.jgss/sun.security.krb5.Credentials.acquireDefaultCreds(Credentials.java:449) at java.security.jgss/sun.security.krb5.Credentials.acquireTGTFromCache(Credentials.java:335) at jdk.security.auth/com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:649) at jdk.security.auth/com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:601) at java.base/javax.security.auth.login.LoginContext.invoke(LoginContext.java:603) at java.base/javax.security.auth.login.LoginContext.login(LoginContext.java:460) at RunWhoAmI.main(RunWhoAmI.java:22) ...without libkrb5, but with a small patch to also catch `UnsatisfiedLinkError`: krb5loginmodule[0x3|main|Krb5LoginModule.java:647|2025-11-18 13:52:09.045]: Acquire TGT from Cache krb5loginmodule[0x3|main|Krb5LoginModule.java:678|2025-11-18 13:52:09.053]: Principal is null krb5loginmodule[0x3|main|Krb5LoginModule.java:681|2025-11-18 13:52:09.053]: null credentials from Ticket Cache krb5loginmodule[0x3|main|Krb5LoginModule.java:608|2025-11-18 13:52:09.054]: [Krb5LoginModule] authentication failed Unable to obtain Principal Name for authentication Login failed javax.security.auth.login.LoginException: Unable to obtain Principal Name for authentication at jdk.security.auth/com.sun.security.auth.module.Krb5LoginModule.promptForName(Krb5LoginModule.java:816) at jdk.security.auth/com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:693) at jdk.security.auth/com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:601) at java.base/javax.security.auth.login.LoginContext.invoke(LoginContext.java:603) at java.base/javax.security.auth.login.LoginContext.login(LoginContext.java:460) at RunWhoAmI.main(RunWhoAmI.java:22) ------------- PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3549110005
