ZMQ_GSSAPI_PRINCIPAL sockopt has no effect on client side

[garlick]

I am trying to get GSSAPI security working with my application, and indeed seem have it going with libzmq 4.1.4 and czmq 3.0.2. (My compliments to the author for getting this integrated with the libzmq security framework!) However, this one quirk puzzles me:

Setting ZMQ_GSSAPI_PRINCIPAL (e.g. with czmq 3.0.2 zsock_set_gssapi_principal() seems not to matter on the client end. I can set it to a random string, or not set it all, and authentication still works using the default principal, presumably figured out by the underlying libkrb5. It does not seem possible to influence the choice of principal, even when several are available in the credential cache.

This would seem contrary to how @cbusbey's gist indicates it should work.

If anyone else is working with GSSAPI perhaps they can confirm these results, or explain why this is OK. Meanwhile I will try to put together a simple reproducer.

TL;DR downstream issue is flux-framework/flux-core#758

[bluca]

I can't say I'm familiar with GSSAPI, but the only thing that ZMQ_GSSAPI_PRINCIPAL variable seem to be used for is this call to acquire_credential:

https://github.com/zeromq/libzmq/blob/master/src/gssapi_client.cpp#L63

Does it ring a bell?

[garlick]

Maybe, though I'm also not too familiar. Still I'll have a go :-)

According to zmq_gssapi(7) ZMQ_GSSAPI_PRINCIPAL sockopt is supposed to be set on both client and server side. acquire_credential() definitely works correctly on the server side to establish the service principal that must match the client's service principal (set with a different sockopt).

On the client side, the "service_name" arg to acquire_credential() is the client principal yet the GSS_C_NT_HOSTBASED_SERVICE flag is unconditionally set in the name provided to the second arg of gss_acquire_cred().

According to https://web.mit.edu/kerberos/krb5-1.12/doc/appdev/gssapi.html

If the desired name for a krb5 initiator credential is a host-based name, it is converted to a principal name of the form service/hostname in the local realm, where hostname is the local hostname if not specified.

Hmm, maybe that's causing gss_acquire_cred() to fail?

If so, a secondary question is: if acquire_credentials() returns -1, why does auth proceed on the socket using the default principal? Seems like it should fail in that case.

[bluca]

Sorry but again never used this features - if you find any issues and have a fix, given it sounds like you have a way to test them, please do send PRs

[garlick]

Getting a PR together and still digging through gssapi to grok better, but wanted update status and ask for feedback from @cbusbey if he's still out there?

First, it seems that autoconf support for --with-libgssapi_krb5 was broken on current master by 09e868b (Mar 3, 2016) which changed from AC_CHECK_LIB to AC_SEARCH_LIBS. I guess the latter doesn't define HAVE_LIBGSSAPI_KRB5? The gssapi code is ifdef compiled out if that's not defined. Maybe it works with cmake - haven't checked.

Second, a documentation issue: zmq_gssapi(7) says that ZMQ_GSSAPI_PRINCIPAL must be set on both client and server. It seems to actually be optional; the default principal will be used if it's not set.

Finally, ZMQ_GSSAPI_PRINCIPAL on the client side fails when a valid principal is provided because acquire_credentials() calls gss_acquire_cred() with cred_usage=GSS_C_ACCEPT, which means for acceptors (servers) only. That should be GSS_C_BOTH if it's to also work for initiators (clients). On the other hand, if a bogus principal is provided, it falls through to using the default principal without an error, which may or may not be a bug.

[bozorgi]

I can still see that ZMQ_GSSAPI_PRINCIPAL has no effect on the client socket...
My test was done by using clrzmq4 wrapper though... and it does not matter what I set for ZMQ_GSSAPI_PRINCIPAL on the client side; it works by ay arbitrary string value...
I thought it has been fixed by this commit... any idea?

[garlick]

Yeah, that is what was fixed here. The fix landed in libzmq-4.2.4. What version of libzmq is clrzmq4 using underneath? (Disclaimer: I am not familiar with that binding).

[bozorgi]

Thank you for the answer.... it seems i am using the older version of 4.2.4