[rfc][icedtea7] Handle alternative Kerberos credential cache locations

Elliott Baron ebaron at redhat.com
Wed Aug 14 08:31:10 PDT 2013


Hi Andrew,

On 08/14/2013 10:54 AM, Andrew Hughes wrote:
> ----- Original Message -----
>> Hi,
>>
>> Kerberos 1.11 introduced a new configuration variable to override the
>> default location of the credential cache at build time. Fedora 18 and up
>> have used this new configuration variable to define an alternate default
>> cache location (/run/user/$UID/krb5cc/tkt). This bug was initially
>> reported against Fedora [1].
>>
>> On Linux and Solaris systems, FileCredentialsCache.getDefaultCacheName()
>> defaults to the previously hard-coded location (/tmp/krb5cc_$UID). This
>> location will be incorrect if Kerberos was built with an alternative
>> credential cache location set. Since this credential cache location can
>> be arbitrary, we need to query the Kerberos API for the correct
>> location. This patch implements this query using a new JNI call, which
>> adds a dependency on libkrb5 for Linux and Solaris systems.
>>
>> This patch was prepared against icedtea7-forest/jdk, changeset afaedb56b499.
>>
>> 2013-08-12  Elliott Baron <ebaron at redhat.com>
>>       * make/sun/security/Makefile: Build krb5/internal/ccache on Linux
>> and Solaris.
>>       *
>> src/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java:
>> Replace
>>       hard-coded cache location with native call to Kerberos API.
>>       * make/sun/security/krb5/internal/ccache/Makefile: New file; builds
>> JNI wrapper for
>>       needed Kerberos API.
>>       *
>> src/solaris/native/sun/security/krb5/internal/ccache/krb5ccache.c: New
>> file; JNI function
>>       to query default cache location from Kerberos API.
>>
>> Thanks,
>> Elliott
>>
>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=991170
>>
>>
> I'm building this now and will commit if it builds fine.  I noticed that the
> copyright header on the new Makefile didn't match that on the new source file,
> so I copied over the one from the source file, as I assume you didn't change
> to working for Oracle mid-patch ;)

Thanks! As far as I know I didn't switch jobs mid-patch ;). The header 
was actually intentional, since this new Makefile is heavily derived 
from one of the existing JNI Makefiles. I was a bit unsure how to deal 
with this header.

Thanks,
Elliott



More information about the distro-pkg-dev mailing list