On Fri, 31 Oct 2025 22:48:53 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:
>
> Minor doc/comment clean-ups
>From a build point of view this is definitely starting to look better. I would
>like to get input from a reviewer in the component team at this point to
>comment on the validity of the change before I spend more time reviewing the
>build aspects.
make/autoconf/lib-krb5.m4 line 47:
> 45: KRB5_FOUND=no
> 46:
> 47: if test "x${with_krb5}" != "x" && test "x${with_krb5}" != "xyes" &&
> test "x${with_krb5}" != "xauto"; then
I think you missed the case where `${with_krb5}` is `no`.
make/autoconf/lib-krb5.m4 line 132:
> 130: AC_MSG_RESULT([$KRB5_FOUND])
> 131: else
> 132: PKG_CHECK_MODULES(KRB5, krb5, [KRB5_FOUND=yes], [KRB5_FOUND=no])
In lib-freetype.m4 we first check if `PKG_CONFIG` has a value before trying to
use it. We also print a result because it seems PKG_CHECK_MODULES is quiet. I
tried your patch here and configure doesn't produce any output in this case, so
I think we should print something.
make/modules/java.security.jgss/Lib.gmk line 101:
> 99:
> 100: ifeq ($(call isTargetOs, linux), true)
> 101: ifeq ($(ENABLE_LIBLINUXKRB5), true)
Suggestion:
ifeq ($(ENABLE_LIBKRB5_LINUX), true)
-------------
PR Review: https://git.openjdk.org/jdk/pull/28075#pullrequestreview-3411106519
PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2486542040
PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2486621470
PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2486550921
