JGSS Enhancements (contribution by Two Sigma Open Source)

[Nico Williams]

On Wed, Mar 06, 2019 at 10:24:50AM +0800, Weijun Wang wrote:
> Tell me the title and description of the bug/RFE, and I'll create one like
> https://bugs.openjdk.java.net/browse/JDK-8212217.

Thanks.  All the commit subject lines work as bug synopses (when they
differ, the commit subject is in parenthesis below proposed synopsis):

 - (bug) Add missing dbgsysGetLastErrorString()

   dbgsys*() are wrappers around dlopen() (Unix) / LoadLibrary()
   (Windows).  A binding for dlerror() was missing.

 - (bug) cut/paste error in NativeUtil.c
   (Fix cut/paste error in NativeUtil.c)

 - (RFE) Cleanup error handling in GSSLibStub
   (Fix error handling in GSSLibStub)

 - (RFE) Need a String to gss_buffer_t conversion utility
   (Implement String to gss_buffer_t import)

 - (bug) GSS_S_FAILURE major status lost in importContext
   (Fix loss of GSS_S_FAILURE major status in importContext)

 - (bug) GSSNameElement constructor needs actual mechanism input
   (Add actual mechanism to native GSSNameElement state)

 - (RFE) Add getLocalName() GSSName method

 - (RFE) Add createCredential() with password

 - JDK-8212217 (exists)

 - (bug) SpNego multi-round-trip bug
   (Fix SpNego multi-round-trip bug)

 - (RFE) ServicePermission empty realm support

 - (bug) GSSCredentialSpineeds isDefaultCredential() method
   (Add isDefaultCredential() method to GSSCredentialSpi)

 - (bug) Prefer default cred handles if possible
   (JGSS: Prefer default cred handles if possible)

 - (bug) GSSName should extend Principal
   (Make GSSName implement Principal (add getName()))

   This is the key bug.  Without this a GSSName backed by the native C
   GSS-API library cannot be used with JAAS.

   Note that GSS name objects conceptually *are* principals.  The base
   RFCs, 2743 and 2744, both refer to them as such.

   A GSSName is notionally no different that a Krb5Principal, except as
   to implementation details.

 - (bug/RFE) Add GssLoginModule

   Naturally, Krb5LoginModule is not appropriate when using the native C
   GSS-API library.  That makes the non-existence of GssLoginModule a
   bug when using the native C GSS-API library.

   Arguably, JAAS's continued existence in a world without applets is a
   bug!  I would prefer JAAS be removed, but there is a great deal of
   cargo-culted JAAS-using application code out there that will not go
   away anytime soon, so at the very least stub classes and methods
   would have to stay behind.

   This commit adds a GssLoginModule that is almost a complete
   replacement for Krb5LoginModule.

   Missing functionality to make it a complete replacement of
   Krb5LoginModule:

    - kinit with key    (maps to gss_acquire_cred_from())
    - kinit with keytab (maps to gss_acquire_cred_from())

 - (RFE) Krb5LoginModule cleanup

 - (bug) Output actual mechanism
   (fixup SEAM bug uncomments)

 - (bug) Memory leak in exception cases in getJavaOID()
   (Fix leak in exception cases in getJavaOID())

 - (RFE) Simplify Krb5 context permissions checks
   (JGSS: Simplify context permissions checks)

 - (bug) Dispose of delegated cred handles early

   Like JDK-8212217.

   When a Java object has an associated C object, it's important to
   dispose() of the C object as soon as possible.  The GC does not know
   there there is more memory pressure due to that C object.  Java
   objects with unknown-to-the-GC C objects are icebergs.


> You're an author now, right? You can post one yourself, webrev is at https://hg.openjdk.java.net/code-tools/webrev.

OK, I'll figure that out.

> > So Peter, for example, doesn't need to be a contributor?
> 
> Anyone can reply, but to push the change, a formal openjdk reviewer is needed.

OK, thanks.

> If Peter rewrite the patch in total then he might need to sign the OCA.

That will not be the case.

> > Right, GitHub is sure a lot more convenient than webrevs.
> 
> Hope so, but I do switch between the udiff, sdiff, frames and new
> views of webrev a lot. It's not very friendly to comment of course.

This could be fixed though.  I'm surprised that webrev still doesn't
have a comment facility all these years later.  I left Sun (Oracle) in
2011 -- that webrev has hardly changed since it was created (when was
that?  I want to say it was around 2003) is a testament to its utility,
but it is also surprising because writing code review comments in e-mail
takes a lot more time than on a web page.

Nico
--