Uploaded image for project: 'Documentation'
  1. Documentation
  2. DOCS-13532

Docs for SERVER-40560: Ensure system-collection protections for local and config system collections

      Description

      Description:

      No documentation summary in engineering ticket

      Engineering Ticket Description:

      Normal write permissions are the only requirement for writing to the following collections in `local`:

      replset.election
      replset.minvalid
      replset.oplogTruncateAfterPoint
      startup_log
      

      Could we require more explicit write privileges
      to prevent changing these collections?

      original description

      I'm doing testing of interacting with mongo and replicaset. And during the test suite, we start up a Mongodb, and clean it up between tests. One of our tests is testing the infrastructure can recover if a test resets a password and the server needs to be torn down and set up again.

      Without --replSet having been set, the test passes just fine. With --replSet, I get a failure with this backtrace:

       mongod(_ZN5mongo15printStackTraceERSo+0x3A) [0x5650b0d4597a]
       mongod(+0x222EC3E) [0x5650b0d44c3e]
       mongod(+0x222F112) [0x5650b0d45112]
       libpthread.so.0(+0x12890) [0x7ff109b80890]
       libc.so.6(gsignal+0xC7) [0x7ff1097bbe97]
       libc.so.6(abort+0x141) [0x7ff1097bd801]
      mongod(_ZN5mongo22invariantFailedWithMsgEPKcRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES1_j+0x0) [0x5650af3d90e4] mongod(_ZNK5mongo4repl33ReplicationConsistencyMarkersImpl11getMinValidEPNS_16OperationContextE+0x258) [0x5650af6c7d78] mongod(_ZN5mongo4repl8SyncTail17_oplogApplicationEPNS0_11OplogBufferEPNS0_22ReplicationCoordinatorEPNS1_14OpQueueBatcherE+0x170) [0x5650af79c2c0]
      mongod(_ZN5mongo4repl8SyncTail16oplogApplicationEPNS0_11OplogBufferEPNS0_22ReplicationCoordinatorE+0x11E) [0x5650af79d8ee]
       mongod(+0xC76EB6) [0x5650af78ceb6] mongod(_ZN5mongo8executor22ThreadPoolTaskExecutor11runCallbackESt10shared_ptrINS1_13CallbackStateEE+0x19A) [0x5650b05dc13a]
       mongod(+0x1AC682A) [0x5650b05dc82a]
       mongod(_ZN5mongo10ThreadPool10_doOneTaskEPSt11unique_lockISt5mutexE+0x1AF) [0x5650b056181f]
       mongod(_ZN5mongo10ThreadPool13_consumeTasksEv+0xAA) [0x5650b0561b5a]
      mongod(_ZN5mongo10ThreadPool17_workerThreadBodyEPS0_RKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE+0x95) [0x5650b05624c5]
       libstdc++.so.6(+0xBD57F) [0x7ff10a40057f]
       libpthread.so.0(+0x76DB) [0x7ff109b756db]
       libc.so.6(clone+0x3F) [0x7ff10989e88f]
      -----  END BACKTRACE  -----
      2019-04-10T17:36:10.691+0400 I NETWORK  [conn6] end connection 127.0.0.1:44610 (0 connections now open
      

       
      Digging through the code it seems to be this invariant:

      https://github.com/mongodb/mongo/blob/master/src/mongo/db/repl/replication_consistency_markers_impl.cpp#L117

      bool ReplicationConsistencyMarkersImpl::getInitialSyncFlag(OperationContext* opCtx) const {     
                  auto doc = _getMinValidDocument(opCtx);
                  invariant(doc);  // Initialized at startup so it should never be missing.
      

      I don't know why the doc is missing in this case.

       

       

      Scope of changes

      Impact to Other Docs

      MVP (Work and Date)

      Resources (Scope or Design Docs, Invision, etc.)

            Assignee:
            andrew.feierabend@mongodb.com Andrew Feierabend (Inactive)
            Reporter:
            kay.kim@mongodb.com Kay Kim (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              1 year, 25 weeks, 1 day ago