[SERVER-59085] Remove _isSelf/saslStart/saslContinue/buildinfo/authenticate from allowlist for OP_QUERY commands Created: 03/Aug/21  Updated: 22/Nov/23

Status: Backlog
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Yoon Soo Kim Assignee: Backlog - Query Execution
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Related
Assigned Teams:
Query Execution
Backwards Compatibility: Major Change
Participants:

 Description   

At the very late stage of PM-912 project, we realized that repl code is sending _isSelf/saslStart/saslContinue as OP_QUERY commands (see SERVER-58338) and some drivers are still using saslStart/saslContinue/buildinfo/authenticate OP_QUERY commands as part of connection handshake (see SERVER-59069). Unfortunately, we could not change existing code and decided to allow those OP_QUERY commands.

We should remove _isSelf/saslStart/saslContinue/buildinfo/authenticate OP_QUERY commands from allowlist for the v6.0 release. To remove saslStart/saslContinue/buildinfo/authenticate, we may need to coordinate the efforts with drivers team since some drivers are using them.



 Comments   
Comment by David Storch [ 12/May/23 ]

I noticed that this was marked with a "7.0 Desired" fixVersion, but there are no plans for it to go into 7.0. Marking this for re-triage. We could choose to just close it or to work with drivers to figure out a safe plan for making this change that wouldn't affect users (unless perhaps they were using extremely old driver versions).

Comment by Jeffrey Yemin [ 27/Jan/22 ]

I recommend that we defer this work until API Version "2" due to a few facts on the ground:

  1. Drivers release with API version "1" support rely on the current behavior, and we have been sending the message that as of those releases, it's not necessary to upgrade to latest drivers when upgrading the server, since both support API version "1"
  2. Even with strict mode enabled for API version "1", the server does not reject OP_QUERY messages for these commands. While this may have been an oversight (and one that would have caught this problem in drivers sooner), it means that even applications that specify strict mode for API version "1" would not be compatible with a future server release that implemented this ticket, unless they also upgrade their driver.
Comment by David Storch [ 26/Jan/22 ]

I'm marking this ticket to be re-triaged. We should not do this in 6.0 so that pre-existing drivers which use OP_QUERY to authenticate will keep working with a 6.0 server. However, we should consider doing this in some future release where the server need not be compatible with such older drivers.

Comment by Yoon Soo Kim [ 10/Aug/21 ]

Would it be possible to try OP_MSG-based connection handshake first and if it fails, we fall back to OP_QUERY-based connection handshake? Do we know the percentage of 3.4 and older servers?

Comment by David Storch [ 10/Aug/21 ]

ethan.zhang I don't think it's worth filing a follow-up project. We've achieved the most of the code simplifications that we set out to do. The remaining work which we've chosen to cut is quite minor, with the exception of SERVER-58491. The remaining work can be scheduled via quick wins, neweng, or simply not scheduled at all.

This particular ticket is in a different category because it cannot be done for correctness reasons at least until at least after releasing the 6.0 LTS release.

Comment by Ethan Zhang (Inactive) [ 10/Aug/21 ]

david.storch Now seeing this and some other tickets being removed from PM-912 I start to think maybe we should create another PM ticket to group them together. Like a follow-up project. Do you think that makes sense? Or I can see them go to the quick win epic as well.

Generated at Thu Feb 08 05:46:18 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.