[SERVER-34495] MongoDB Shell does not validate URI for replicaSet option Created: 16/Apr/18  Updated: 31/Jan/19  Resolved: 31/Jan/19

Status: Closed
Project: Core Server
Component/s: Shell
Affects Version/s: 3.6.3, 3.6.4
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Arnie Listhaus Assignee: Alyson Cabral (Inactive)
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-39317 Make connection uri options case inse... Closed
related to SERVER-39318 Warn in the shell when using a unreco... Closed
related to SERVER-39319 Warn in the shell when connecting to ... Closed
Operating System: ALL
Steps To Reproduce:

Specify a mongodb uri without using the replicaSet option on a replica set whose first member listed is not the primary

Sprint: Security 2018-11-19, Service Arch 2019-02-11
Participants:

 Description   

The 3.6 version of the MongoDB Shell does not error if the replicaSet option is missing. When missing, connection appears to be to first node in the URI list.

In example below, I have used replicaset as the option without an upper case 'S' ie replicaset vs replicaSet.

Arnies-MacBook-Pro:repl3 arnielisthaus$ m 3.6.3
Arnies-MacBook-Pro:repl3 arnielisthaus$ mongo mongodb://localhost:27017,localhost:27018,localhost:27019/?replicaset=replset
MongoDB shell version v3.6.3
connecting to: mongodb://localhost:27017,localhost:27018,localhost:27019/?replicaset=replset
MongoDB server version: 3.6.3
Mongo-Hacker 0.0.14
Server has startup warnings:
2018-04-16T11:44:58.341-0400 I CONTROL  [initandlisten]
2018-04-16T11:44:58.341-0400 I CONTROL  [initandlisten] ** WARNING: Access control is not enabled for the database.
2018-04-16T11:44:58.341-0400 I CONTROL  [initandlisten] **          Read and write access to data and configuration is unrestricted.
2018-04-16T11:44:58.341-0400 I CONTROL  [initandlisten]
2018-04-16T11:44:58.341-0400 I CONTROL  [initandlisten] ** WARNING: This server is bound to localhost.
2018-04-16T11:44:58.342-0400 I CONTROL  [initandlisten] **          Remote systems will be unable to connect to this server.
2018-04-16T11:44:58.342-0400 I CONTROL  [initandlisten] **          Start the server with --bind_ip <address> to specify which IP
2018-04-16T11:44:58.342-0400 I CONTROL  [initandlisten] **          addresses it should serve responses from, or with --bind_ip_all to
2018-04-16T11:44:58.342-0400 I CONTROL  [initandlisten] **          bind to all interfaces. If this behavior is desired, start the
2018-04-16T11:44:58.342-0400 I CONTROL  [initandlisten] **          server with --bind_ip 127.0.0.1 to disable this warning.
2018-04-16T11:44:58.342-0400 I CONTROL  [initandlisten]
Arnies-MacBook-Pro(mongod-3.6.3)[SECONDARY:replset] test>

The same is true if no options or any invalid options are passed.

In 3.4, the URI was validated e.g.:

Arnies-MacBook-Pro:repl3 arnielisthaus$ m 3.4.9
Arnies-MacBook-Pro:repl3 arnielisthaus$ mongo mongodb://localhost:27017,localhost:27018,localhost:27019/?replicaset=replset
FailedToParse: Cannot list multiple servers in URL without 'replicaSet' option
try 'mongo --help' for more information



 Comments   
Comment by Alyson Cabral (Inactive) [ 31/Jan/19 ]

I'm going to close this ticket as won't fix, because we will not be going back to requiring you to specify the replica set name (so that you can connect to multiple mongos routers). I believe the 3 linked tickets will mitigate the negative impact of this behavior change. 

Comment by Alyson Cabral (Inactive) [ 31/Jan/19 ]

OK, great there are 3 tickets I created based on your test cases:

(1) SERVER-39317 describes how case 2 and 3 should be equivalent in 3.6 and 4.0

(2) SERVER-39318 I disagree that for case 5 the behavior is incorrect, due to backward compatibility concerns where we want new/old versions of the server to ignore uri options it doesn't recognize. However, I believe we should log a message. 

(3) SERVER-39319 case 4 is the correct behavior because the only way you can connect to multiple mongos routers is by specifying multiple servers without the replicaSet name. I want us to consider adding a warning to our shell in the case where you: connect to multiple servers that aren't mongos (so replicas or standalones) routers without the replicaSet name. This should likely also be a drivers spec change.

 

cc: behackett

 

Comment by Alexey Menshikov [ 31/Jan/19 ]

No. There's only one replica set with name "replset". "replset45" is just a random name of non-existing replica set.

Comment by Alyson Cabral (Inactive) [ 31/Jan/19 ]

alexey.menshikov in your test cases is replica45 a real replica set? 

Comment by Alexey Menshikov [ 30/Jan/19 ]

The issue is confirmed for 3.6 and 4.0. mongoshell ignores low case parameter and able to connect without any replica set name specified or wrong replicaset specified in low case parameter.

Test cases:

1. mongo "mongodb://localhost:27017,localhost:27018,localhost:27019/?replicaSet=replset"
Correct behavior
3.4.19 - Connection success
3.6.10 - Connection success
4.0.5 - Connection success

2. mongo "mongodb://localhost:27017,localhost:27018,localhost:27019/?replicaSet=replset45"
Correct behavior
3.4.19 - All nodes for set replset45 are down
3.6.10 - Cannot reach any nodes for set replset45
4.0.5 - Cannot reach any nodes for set replset45

3. mongo "mongodb://localhost:27017,localhost:27018,localhost:27019/?replicaset=replset45"
Wrong behavior for 3.6 and 4.0
3.4.19 - FailedToParse: Cannot list multiple servers in URL without 'replicaSet' option
3.6.10 - Connection success
4.0.5 - Connection success

4. mongo "mongodb://localhost:27017,localhost:27018,localhost:27019/"
Wrong behavior for 3.6 and 4.0
3.4.19 - FailedToParse: Cannot list multiple servers in URL without 'replicaSet' option
3.6.10 - Connection success
4.0.5 - Connection success

5. mongo "mongodb://localhost:27017,localhost:27018,localhost:27019/?replicaset1kjlh=rlknjasklfnkladsn5"
Wrong behavior
3.4.19 - FailedToParse: Cannot list multiple servers in URL without 'replicaSet' option
3.6.10 - Connection success
4.0.5 - Connection success

Comment by Daniel Pasette (Inactive) [ 16/Apr/18 ]

This was changed in SERVER-31061. If I'm reading the specification correctly, it states that we should ignore case when parsing options. In which case the prior validation behavior was also incorrect.

Generated at Thu Feb 08 04:36:52 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.