[PATCH] Fix failure of mech plugins lacking gss_inquire_attrs_for_mech()

[Greg Hudson]

On 03/15/2016 07:48 PM, David Woodhouse wrote:
> Yes, that fixes it. But I'm still unhappy. The "alternative" fix was to
> implement gss_inquire_attrs_for_mech() in gssntlmssp, and just to
> return GSS_C_NO_OID_SET for both supported and known mechanism sets. As
> seen in http://david.woodhou.se/0001-Add-gss_inquire_attrs_for_mech.patch
> 
> With that patch to gssntmssp, it appears that the code in the generic
> gss_inquire_attrs_for_mech() function is still going to override the
> GSS_C_NO_OID_SET that I explicitly returned as the known_mech_attrs,
> and wrongly assume that all attrs listed in RFC5587 are known.
>
> Why?

I said most of this in the PR already, but: the mechglue implementation
of gss_inquire_attrs_for_mech() (which I did not write) includes a
convenience for mechanisms which understand exactly the RFC 5587
attributes and no more.  The convenience is that if the mechanism leaves
(or explicitly sets) a null oid set in known_mech_attributes, the RFC
5587 attribute set will be placed there.

I do not particularly like this convenience, because it makes the SPI
different from the API without a good reason, and because it stops being
helpful as soon as a mechanism supports any attributes beyond the RFC
5587 set.  But it would not necessarily be safe to remove the
convenience.  The krb5 and SASL implementations of the function take
advantage of it, and it is possible that some loadable mechanisms do as
well.

All that aside, I don't believe that a mechanism should implement
gss_inquire_attrs_for_mech() without knowledge of the RFC 5587 attribute
set.  If you really want to do so, you can create an empty-but-not-NULL
gss_OID_set for the known mechanism attributes, bypassing the mechglue
convenience feature.

I have pushed PR #426 to master.