[SERVER-79630] Disallow creating and preventing upgrading with system.buckets namespaces which aren't timeseries collections Created: 02/Aug/23  Updated: 05/Feb/24

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

Type: Improvement Priority: Major - P3
Reporter: Max Hirschhorn Assignee: Backlog - Storage Execution Team
Resolution: Unresolved Votes: 0
Labels: time-series
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-79499 "Fix" non-time-series bucket collecti... In Code Review
Related
is related to SERVER-79499 "Fix" non-time-series bucket collecti... In Code Review
Assigned Teams:
Storage Execution
Participants:

 Description   

Prior to MongoDB 5.0 it wasn't possible for an external client to create a system.buckets collection, even if such a client was authenticated as the __system user. This is because collections which are prefixed with system. are protected at a level outside the access control system where unrecognized system collections cannot be created (full stop). With the introduction of timeseries collections in MongoDB 5.0, this constraint was relaxed and it became possible for external clients to create system.buckets collections directly. The intended use case was likely for mongorestore for performance reasons to directly write the bucket documents. However despite the only valid use case for system.buckets collection to be for a timeseries collection, this isn't actually enforced by the server at all.

This gap in input validation leaves open a risk where Server engineers make poor assumptions about NamespaceString::isTimeseriesBucketsCollection() implying the collection is actually timeseries without consulting the local mdb catalog. Or where mongosync wants to rely on checking whether the namespace has a system.buckets. prefix and therefore requires special DDL handling to deal with the associated view namespace. We should instead move the server semantics into one where the assumptions engineers are making turn out also to be true.

rs:PRIMARY> db.dropDatabase()
rs:PRIMARY> db.system.buckets.a.runCommand("create")
{
        "ok" : 1,
        "$clusterTime" : {
                "clusterTime" : Timestamp(1690936687, 1),
                "signature" : {
                        "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
                        "keyId" : NumberLong(0)
                }
        },
        "operationTime" : Timestamp(1690936687, 1)
}



 Comments   
Comment by Gregory Noma [ 08/Aug/23 ]

CC michael.gargiulo@mongodb.com nishith.atreya@mongodb.com

Generated at Thu Feb 08 06:41:29 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.