[SERVER-20740] External exception not handled well by SASL/LDAP implementation Created: 02/Oct/15 Updated: 07/Dec/16 Resolved: 03/Jun/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Networking, Security |
| Affects Version/s: | 2.6.9 |
| Fix Version/s: | 3.3.8 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Steven Hand | Assignee: | Spencer Jackson |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Operating System: | ALL | ||||||||||||
| Steps To Reproduce: | 1) Step sharded cluster |
||||||||||||
| Sprint: | Security B 10/30/15, Security C 11/20/15, Security D (12/11/15), Security E (01/01/16), Security F (01/29/16), Security 10 (02/19/16), Security 11 (03/11/16), Security 12 (04/01/16), Security 13 (04/22/16), Security 15 (06/03/16) | ||||||||||||
| Participants: | |||||||||||||
| Description |
|
The Mongos authorization code does not handle exceptions raised by the Cyrus SASL implementation and crashes. |
| Comments |
| Comment by Githook User [ 03/Jun/16 ] | ||||||||||||||||||||||
|
Author: {u'username': u'spencerjackson', u'name': u'Spencer Jackson', u'email': u'spencer.jackson@mongodb.com'}Message: | ||||||||||||||||||||||
| Comment by Githook User [ 03/Jun/16 ] | ||||||||||||||||||||||
|
Author: {u'username': u'spencerjackson', u'name': u'Spencer Jackson', u'email': u'spencer.jackson@mongodb.com'}Message: | ||||||||||||||||||||||
| Comment by Steven Hand [ 02/Oct/15 ] | ||||||||||||||||||||||
|
The versions of OS and supporting libraries in the environment experiencing the issue:
| ||||||||||||||||||||||
| Comment by Steven Hand [ 02/Oct/15 ] | ||||||||||||||||||||||
|
The operative theory is that an exception is being thrown from within MongoS's authorization code when attempting to acquire a password from the configure servers on the behalf of Cyrus SASL. A guess is that while creating ScopedDbConnection to the config server, the constructor timed out and threw an exception which propagated back to our call back, and tried to pass into C code. A possible solution would be wrapping the authorization logic in the Enterprise Module with a try/catch block to consume any and all exception raised by the internal authorization code before they propagate back to C (while still within the C++ code). | ||||||||||||||||||||||
| Comment by Steven Hand [ 02/Oct/15 ] | ||||||||||||||||||||||
|
This issue was experience with a configuration of three {{mongos} servers and a config server. The stack trace produced was:
|