Problem: principals are looked up unconditionally
with the GSS_C_NT_HOSTBASED_SERVICE name type.
Solution: Add two new socket options to set the name type
for ZMQ_GSSAPI_PRINCIPAL and ZMQ_GSSAPI_SERVICE_PRINCIPAL:
ZMQ_GSSAPI_PRINCIPAL_NAMETYPE
ZMQ_GSSAPI_SERVICE_PRINCIPAL_NAMETYPE
They take an integer argument which must be one of
ZMQ_GSSAPI_NT_HOSTBASED (0) - default
ZMQ_GSSAPI_NT_USER_NAME (1)
ZMQ_GSSAPI_NT_KRB5_PRINCIPAL (2)
These correspond to GSSAPI name types of:
GSS_C_NT_HOSTBASED_SERVICE
GSS_C_NT_USER_NAME
GSS_KRB5_NT_PRINCIPAL_NAME
Fixes#2542
Problem: if client sets the ZMQ_GSSAPI_PRINCIPAL to a valid
principal, authentication fails.
When an application sets ZMQ_GSSAPI_PRINCIPAL, whether as a
client or a server, libzmq internally calls gss_acquire_cred()
with cred_usage=GSS_C_ACCEPT. This cred_usage setting is for
acceptors (servers) only, thus it doesn't work for initiators
(clients).
Solution: Change the cred_usage parameter to GSS_C_BOTH to allow
initiators to set ZMQ_GSSAPI_PRINCIPAL.
The gssapi has some helper functions gssalloc_malloc()/gssalloc_free()
which on windows doesn't call malloc()/free(). Instead these are
wrappers around HeapAlloc() and HeapFree(). To complicate matters
gssapi doesn't export these helper functions, so you're left using
the allocation method of your choice.
See Here:
89683d1f13/src/lib/gssapi/generic/gssapi_alloc.h
The zmq gssapi implementation is calling malloc and then calling
gss_release_buffer() to free the memory. gss_release_buffer uses
gssalloc_free() to free this buffer which on windows calls HeapFree()
instead of free(). This causes an access violation on windows.
Of course people still "can" distributed the sources under the
LGPLv3. However we provide COPYING.LESSER with additional grants.
Solution: specify these grants in the header of each source file.
