[SERVER-49031] Allow replSetGetConfig with localhost exception Created: 23/Jun/20  Updated: 06/Dec/22  Resolved: 23/Jun/20

Status: Closed
Project: Core Server
Component/s: Replication, Security
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Judah Schvimer Assignee: Backlog - Replication Team
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Replication
Participants:

 Description   

replSetReconfig is allowed with the localhost exception, so it's odd (and causes some testing headaches) for replSetGetConfig to not be allowed.

With Initial Sync Semantics, users may want to call replSetGetConfig more to get the current config version when creating new configs. For reconfig to be safe, you can only add one node at a time, so you may need to do more back to back reconfigs. You also need to call replSetGetConfig with the "commitmentStatus" to know when your current reconfig is committed.



 Comments   
Comment by Siyuan Zhou [ 23/Jun/20 ]

I don't see why users would rely on local exception to reconfig. I understand the inconsistence of the behaviors, but don't see immediate problems of that. I'd lean towards fixing the inconsistence when it becomes an issue, unless it makes your testing easier.

Comment by Judah Schvimer [ 23/Jun/20 ]

From talking to Spencer:

replSetReconfig is allowed with the localhost exception because the administrator needs to be able to elect a primary in order to create the first user. This means that we only actually need to allow replSetInitiate with the localhost exception (since that's sufficient to get a primary). replSetInitiate and replSetReconfig have the same privilege, so users get replSetReconfig privileges even though they don't strictly need it. This seems fine, and has been the behavior for quite some time.

Spencer would prefer not to permit replSetGetConfig if it is not essential, so we likely should close this "Won't Fix".

siyuan.zhou, do you see any reason from Safe Reconfig why we'd need to do this ticket?

Comment by Judah Schvimer [ 23/Jun/20 ]

spencer.jackson, what are your thoughts on this?

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