[SERVER-45584] Validate writeConcern.w Created: 15/Jan/20  Updated: 29/Oct/23  Resolved: 31/Jan/20

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 4.3.3, 4.3.4

Type: Bug Priority: Major - P3
Reporter: Benjamin Caimano (Inactive) Assignee: Amirsaman Memaripour
Resolution: Fixed Votes: 0
Labels: bson, save-for-sam
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Cloners
is cloned by SERVER-45920 Validate writeConcern.w Closed
Depends
Related
related to CDRIVER-3510 Tests with invalid write concern of w... Closed
is related to SERVER-45639 Use safeNumberLong() to parse wTimeou... Closed
is related to SERVER-45837 Modify an existing dynamic builder to... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Service Arch 2020-02-10
Participants:
Linked BF Score: 95

 Description   

We attempt to use numberInt() to load integers from the wire here and here. Both of these should be safeNumberLong() calls instead. The wNumNodes value should also be validated against the maximum amount of nodes in a replica set before it gets downcasted to int.



 Comments   
Comment by Ratika Gandhi [ 31/Jan/20 ]

Closing this ticket to avoid any future confusion over the fixVersions of commits related to this ticket. I have cloned the ticket details in SERVER-45920 which will be used for any future commits related to this bug. 

Comment by Eric Milkie [ 29/Jan/20 ]

Note that this was released in 4.3.3 but was reverted in this same ticket for 4.3.4. Sorry for the confusion. The reversion should have been done in a separate ticket since this change was released downstream.

Comment by Kevin Albertson [ 29/Jan/20 ]

Should this be reopened? The change was released on 4.3.3 but reverted on master. The difference of error reporting broke one test in the C driver, which was testing the server validation of a user passing w:99. It is a small change to fix our test, but I'll watch this ticket for updates in case the revert is released.

Comment by Githook User [ 29/Jan/20 ]

Author:

{'name': 'Amirsaman Memaripour', 'email': 'amirsaman.memaripour@10gen.com'}

Message: Revert SERVER-45584
Branch: master
https://github.com/mongodb/mongo/commit/bb57005306f9d0aeb310a33384cb0a31df3490aa

Comment by Dianna Hohensee (Inactive) [ 29/Jan/20 ]

It appears that this commit has broken my compile with opt=off. The write_concern_options.cpp file is using repl_set_config.h, but does not link it. However, introducing repl_set_config.cpp to the SCons library for write_concern_options.cpp creates a dependency cycle, like so:

ninja: error: dependency cycle:
build/ninja/mongo/db/repl/libreplica_set_messages.so -> 
    build/ninja/mongo/rpc/libmetadata.so -> 
        build/ninja/mongo/db/liblogical_time_validator.so -> 
            build/ninja/mongo/db/libkeys_collection_manager.so -> 
                build/ninja/mongo/db/libkeys_collection_client_sharded.so -> 
                    build/ninja/mongo/s/catalog/libsharding_catalog_client.so ->
                        build/ninja/mongo/db/libwrite_concern_options.so -> 
                            build/ninja/mongo/db/repl/libreplica_set_messages.so

Comment by Githook User [ 28/Jan/20 ]

Author:

{'email': 'amirsaman.memaripour@10gen.com', 'name': 'Amirsaman Memaripour'}

Message: SERVER-45584 Validate writeConcern.w
Branch: master
https://github.com/mongodb/mongo/commit/8a4dba3b0c26e7649c9da3ce05799782682aa1dc

Comment by Kevin Pulo [ 15/Jan/20 ]

By all means make sure that the w field is a number, int, long, or string. But you can't validate it against the number of nodes, because:

  1. It's perfectly valid to request writeConcern of {w:4} in a 3 member set. The operation will fail with UnsatisfiableWriteConcern, ie. this checking is already in place in the appropriate layer.
  2. writeConcern is given to mongos which then passes it on to the shard(s) for use. mongos has no value for "maximum number of nodes" that it could use, and shards might have different numbers of nodes, etc etc.
Generated at Thu Feb 08 05:09:12 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.