[CDRIVER-2254] Could not authenticate using kerberos authentication with mongoc-driver v1.5.0 Created: 24/Aug/17 Updated: 28/Oct/23 Resolved: 20/Nov/17 |
|
| Status: | Closed |
| Project: | C Driver |
| Component/s: | auth |
| Affects Version/s: | 1.2.4 |
| Fix Version/s: | 1.9.0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Nachiket Goswami | Assignee: | A. Jesse Jiryu Davis |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Description |
|
Based on https://jira.mongodb.org/browse/CDRIVER-323, the canonicalizeHostName flag is being passed in the uri string during kerberos authentication. When using the mongo-c-driver v1.5.0 with kerberos authetication, the driver hangs when using canonicalizeHostName=true. Precisely, the hang takes places inside the _mongoc_cluster_get_canonicalized_name function. This hang was not observed when using the mongo-c-driver v1.1.10. Not sure if this is the cause but the implementation of mongoc_stream_get_base_stream function (called within _mongoc_cluster_get_canonicalized_name) has changed since the 1.1.10 version. If the flag (canonicalizeHostName) is not set at all, then the kerberos authentication mechanism works for the mongo-c-driver v1.5.0. Is using the flag a requirement? The testing was performed with the following setup: MongoDB server version: 3.4.4 (enterprise) MongoDB Client on: Centos7 (tested on Windows 7 as well) In case it is helpful, the format of the connection string being used when using canonicalizedHostName is: mongodb://example%20TEST.COM@mongocdriver:27017/test?authMechanism=GSSAPI&gssapiServiceName=mongodb&canonicalizeHostname=true&connectTimeoutMS=1213&serverSelectionTimeoutMS=1234&socketTimeoutMS=123321 |
| Comments |
| Comment by Githook User [ 20/Nov/17 ] | |
|
Author: {'name': 'A. Jesse Jiryu Davis', 'username': 'ajdavis', 'email': 'jesse@mongodb.com'}Message: The GSSAPI / Kerberos option canonicalizeHostname allows the driver to Fix the infinite loop, and ignore the setting with SSPI, since SSPI | |
| Comment by Bernie Hackett [ 10/Oct/17 ] | |
|
canonicalHostname shouldn't be necessary anywhere but Windows SSPI. MIT krb5 and Heimdal automatically canonicalize the service hostname. Setting that option should have no effect anywhere else. https://web.mit.edu/kerberos/krb5-1.13/doc/admin/princ_dns.html#service-principal-canonicalization | |
| Comment by A. Jesse Jiryu Davis [ 29/Aug/17 ] | |
|
Sorry, I was looking at the wrong commit, I understand what you're telling me now. Yes, I see that starting in version 1.2.0, mongoc_stream_get_base_stream never returns NULL, even if the stream->get_base_stream function pointer is NULL, which causes _mongoc_cluster_get_canonicalized_name to loop forever trying to find the root stream. We should revert that change to mongoc_stream_get_base_stream. As a refactoring, _mongoc_cluster_get_canonicalized_name should call mongoc_stream_get_root_stream so this logic is only implemented in one place. We should unittest _mongoc_cluster_get_canonicalized_name without requiring a Kerberos cluster. If possible we should also test an actual Kerberos cluster in our Evergreen continuous-integration server with "canonicalizeHostName:true". Since you can use Kerberos now by leaving canonicalizeHostName false, I'm scheduling this for a future release, 1.9. | |
| Comment by Nachiket Goswami [ 29/Aug/17 ] | |
|
Thank you for the explanation here. The following is what I observed: 1. I did a quick change locally within mongoc_stream_get_base_stream to return NULL (as was done in 1.1.10) instead of returning stream at the end of the function definition which allowed me to get rid of the hang. 2. 100% CPU is indeed being used by the app during the hang. | |
| Comment by A. Jesse Jiryu Davis [ 29/Aug/17 ] | |
|
The only change in mongoc_stream_get_base_stream after 1.1.10 is that we changed from returning NULL if the passed-in stream is NULL, to asserting that the passed-in stream is not NULL: It doesn't seem to me that this change could result in a hang. In fact, since the caller _mongoc_cluster_get_canonicalized_name asserts that the stream is not NULL after calling mongoc_stream_get_base_stream, it doesn't seem to me that the change to mongoc_stream_get_base_stream can have any effect on hostname canonicalization at all. Can you tell me why you expect that reverting to 1.1.10's implementation of mongoc_stream_get_base_stream should solve this problem? Additionally, can you say whether your application is spinning (using 100% CPU) while it hangs? To answer your question, hostname canonicalization is not required. As you've observed, in your setup Kerberos works without it. It's only necessary if the hostname used in Kerberos authentication does not match a host alias in your connection URI. | |
| Comment by Nachiket Goswami [ 28/Aug/17 ] | |
|
I tested this with the c driver v 1.7 and the hang is still observable even after using the updated connection string syntax. The hang takes places inside mongoc_stream_get_base_stream. I believe the mongoc_stream_get_base_stream() function definition present in v1.1.10 should solve this problem. | |
| Comment by Hannes Magnusson [ 24/Aug/17 ] | |
|
I've got memories of mongoc_stream_get_base_stream having a bug where it would wind up in an endless loop. Could you please try upgrading to 1.7: https://github.com/mongodb/mongo-c-driver/releases/tag/1.7.0 1.5 is pretty old at this point. Btw, those connection uri options have been deprecated. The "correct" way is now:
|