[SERVER-47429] authenticationMechanisms parameter is not validated Created: 09/Apr/20 Updated: 29/Oct/23 Resolved: 20/Apr/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | 4.2.3, 4.3.4 |
| Fix Version/s: | 4.2.7, 4.4.0-rc4, 4.7.0 |
| Type: | Bug | Priority: | Minor - P4 |
| Reporter: | Oleg Pudeyev (Inactive) | Assignee: | Mark Benvenuto |
| Resolution: | Fixed | 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 | ||||
| Backport Requested: |
v4.4, v4.2
|
||||
| Sprint: | Security 2020-04-20, Security 2020-05-04 | ||||
| Participants: | |||||
| Description |
|
If I start a server with authenticationMechanisms set to the empty string it fails:
However if I supply a bogus value for the mechanisms the server seems to start just fine:
It even claims to have accepted ! for the mechanisms:
This becomes a more significant issue when the mechanisms are valid but not for the version of the server that is being launched. For example, the following invocation tries to start 4.2 with the aws mechanism and succeeds (subsequently failing all aws auth authentication attempts):
As a user of the server, I would like the server to validate authenticationMechanisms parameter when it starts so that I am informed when I requested mechanisms that the server does not support, so that I can efficiently remedy the misconfiguration. |
| Comments |
| Comment by Githook User [ 29/Apr/20 ] |
|
Author: {'name': 'Mark Benvenuto', 'email': 'mark.benvenuto@mongodb.com', 'username': 'markbenvenuto'}Message: (cherry picked from commit 817a7f1951189b2a8c7c06fb5fb5361241c1cd57) |
| Comment by Githook User [ 29/Apr/20 ] |
|
Author: {'name': 'Mark Benvenuto', 'email': 'mark.benvenuto@mongodb.com', 'username': 'markbenvenuto'}Message: (cherry picked from commit f85a6c4d38be2a36aec15f5a62a28f56fd2178bd) |
| Comment by Githook User [ 28/Apr/20 ] |
|
Author: {'name': 'Mark Benvenuto', 'email': 'mark.benvenuto@mongodb.com', 'username': 'markbenvenuto'}Message: (cherry picked from commit f85a6c4d38be2a36aec15f5a62a28f56fd2178bd) |
| Comment by Githook User [ 20/Apr/20 ] |
|
Author: {'name': 'Mark Benvenuto', 'email': 'mark.benvenuto@mongodb.com', 'username': 'markbenvenuto'}Message: |
| Comment by Githook User [ 20/Apr/20 ] |
|
Author: {'name': 'Mark Benvenuto', 'email': 'mark.benvenuto@mongodb.com', 'username': 'markbenvenuto'}Message: |
| Comment by Spencer Jackson [ 13/Apr/20 ] |
|
Pretty much, yeah. An out-of-band parameter check seems fine. The service context hook just seemed like an easy place to put the check, because other hooks are responsible for registering the factories, and the assertion has to be made after registration is complete. |
| Comment by Mark Benvenuto [ 13/Apr/20 ] |
|
While we could add some sort of check via the ServiceContext hooks, do you want to just fassert if validation fails? This means we could not tie into the server parameter validation hooks and this would be a special out-of-band parameter check. |
| Comment by Spencer Jackson [ 13/Apr/20 ] |
|
mark.benvenuto, what if we added another ServiceContext initialization action which occurred after all of the mechanism parameters were loaded, and validated that every configured name had a corresponding factory? |
| Comment by Mark Benvenuto [ 13/Apr/20 ] |
|
Spencer.Jackson, This is not possible to fix today because command line/config validation occurs before the SASL mechanisms are registered. SASL mechanisms registered on the ServiceContext which is created after command line/config validation. In order to fix this, we need to make the list of SASL mechanism available during command line validation which means moving the SASL mechanism registry off the Service Context. Let me know if this solution is acceptable or if you have another suggestion. |