[SERVER-49386] Always forbid dropping config.transactions Created: 09/Jul/20  Updated: 02/Oct/20  Resolved: 02/Oct/20

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

Type: Bug Priority: Major - P3
Reporter: Vesselina Ratcheva (Inactive) Assignee: Tess Avitabile (Inactive)
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-47323 If config.system.indexBuilds is dropp... Closed
is related to SERVER-48525 Forbid dropping config.transactions w... Closed
Operating System: ALL
Sprint: Repl 2020-08-24, Repl 2020-09-07, Repl 2020-09-21, Repl 2020-10-05
Participants:

 Description   

This ticket is to consider always banning dropping the transaction table, regardless of its contents. (SERVER-48525 already proposes such a restriction, except only when there are prepared transactions in the system.)

We might have to make an exception for standalone mode so as to not completely prohibit admin intervention.



 Comments   
Comment by Evin Roesle [ 02/Oct/20 ]

tess.avitabile I think the revert would make sense but I also see this as a very low priority unless we start to hear that this has caused pain for customers/support teams. I don't think this is something we would work on in the short to medium future.

Comment by Tess Avitabile (Inactive) [ 01/Oct/20 ]

Our preferred way to restrict usage of collections used by the system is through the access control system. Most of our built-in roles (e.g. readWriteAnyDatabase) exclude privileges on the config database. The only built-in role that permits dropping config.transactions is the restore role. The only additional role that permits modifying documents in config.transactions is the clusterManager role. For this reason, I don't think we need to always forbid dropping config.transactions.

We could consider reverting our previous work to forbid dropping config.transactions when there are prepared transactions, since this prevents arbitrary maintenance of the collection. evin.roesle, what do you think is the priority of this work?

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