Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-90532

ObjectId 3-byte Counter is Not Random for Docker init

XMLWordPrintableJSON

    • Type: Icon: Bug Bug
    • Resolution: Unresolved
    • Priority: Icon: Minor - P4 Minor - P4
    • None
    • Affects Version/s: 5.0 Required, 6.0 Required, 7.0 Required, 5.0.26, 6.0.15, 7.0.9
    • Component/s: None
    • Server Triage
    • ALL
    • Hide

      Steps to Reproduce:

      Using the docker-compose & init.sh (& init.js) content below:
      1. Execute docker compose up mongo

      • check the ObjectId, note the last 3 bytes
      • via the docker logs, or Compass, shell, etc. db.things.find()

      2. Stop the container
      3. Delete the mapped db/ folder
      4. Repeat from step 1 and re-check the ObjectId

       

      docker-compose

      services:
  mongo:
    image: mongo:7
    volumes:
      - ./db:/data/db
      - ./init.sh:/docker-entrypoint-initdb.d/init.sh:ro
    environment:
      MONGO_INITDB_ROOT_USERNAME: root
      MONGO_INITDB_ROOT_PASSWORD: example
    ports:
      - "27017:27017"

      init.sh

      mongosh admin <<EOF
    use example
    db.things.insertOne({ fruit: "apple" });
EOF

       

      Logs will display something like:

      mongo  | /usr/local/bin/docker-entrypoint.sh: running /docker-entrypoint-initdb.d/init.sh
mongo  | admin> switched to db example
mongo  | { acknowledged: true, insertedId: ObjectId('6644c9340857c759862202d8') }

       

      Changing the data being inserted or number of records doesn't affect the outcome. The first item has an ObejctId ending with 2202d8 and the next one is 2202d9

      mongosh admin <<EOF
    use example
    db.things.insertOne({ colour: "blue" });
    db.things.insertOne({ flavour: "banana" });
EOF

      > use example
> db.things.find()
{ _id: ObjectId('6644ca5c25a0c29d5a2202d8'), colour: 'blue' }
{ _id: ObjectId('6644ca5c25a0c29d5a2202d9'), flavour: 'banana' }

       

      These same behaviours can also be reproduced with JavaScript init.js for Mongo 6.x & 7.x:

      init.js

      db.getSiblingDB("example").everything.insertOne({ answer: 42 });
      Show
      Steps to Reproduce: Using the docker-compose & init.sh (& init.js) content below: 1. Execute docker compose up mongo check the ObjectId, note the last 3 bytes via the docker logs, or Compass, shell, etc. db.things.find() 2. Stop the container 3. Delete the mapped db/ folder 4. Repeat from step 1 and re-check the ObjectId   docker-compose services: mongo: image: mongo:7 volumes: - ./db:/data/db - ./init.sh:/docker-entrypoint-initdb.d/init.sh:ro environment: MONGO_INITDB_ROOT_USERNAME: root MONGO_INITDB_ROOT_PASSWORD: example ports: - "27017:27017" init.sh mongosh admin <<EOF use example db.things.insertOne({ fruit: "apple" }); EOF   Logs will display something like: mongo | /usr/local/bin/docker-entrypoint.sh: running /docker-entrypoint-initdb.d/init.sh mongo | admin> switched to db example mongo | { acknowledged: true, insertedId: ObjectId('6644c9340857c759862202d8') }   Changing the data being inserted or number of records doesn't affect the outcome. The first item has an ObejctId ending with 2202d8 and the next one is 2202d9 mongosh admin <<EOF use example db.things.insertOne({ colour: "blue" }); db.things.insertOne({ flavour: "banana" }); EOF > use example > db.things.find() { _id: ObjectId('6644ca5c25a0c29d5a2202d8'), colour: 'blue' } { _id: ObjectId('6644ca5c25a0c29d5a2202d9'), flavour: 'banana' }   These same behaviours can also be reproduced with JavaScript init.js for Mongo 6.x & 7.x: init.js db.getSiblingDB( "example" ).everything.insertOne({ answer: 42 });

      When up'ing a new Docker container for MongoDB 5, 6, 7, and inserting a document in an init.sh script, the 3-byte component of the inserted ObjectId is always the same. The 4-byte timestamp matches the current time and the 5-byte per-process value is different for each execution; so those two components of the ObjectId appear okay.

      In my case, the last 3 bytes for the random counter is always 2202d8 (2228952 in base 10).

      (This behaviour doesn't occur with MongoDB 4.4, 4.2, 4.0)

       

      Notes:

      I've tested this with the following Docker images, with the current version it maps to (in parentheses):

      • mongo:7 (7.0.9)
      • mongo:7.0.8
      • mongo:6 (6.0.15)
      • mongo:5 (5.0.26)
      • mongodb/mongodb-community-server:7.0-ubuntu2204 (7.0.9)
      • mongodb/mongodb-community-server:6.0-ubuntu2204 (6.0.15)

      Even starting the exact same container twice (after deleting the db folder) should not have the same last 3-bytes for Counter, and surely not when starting containers from different images.

       

      The behaviour does not occur for:

      • mongo:4.4
      • mongo:4.2
      • mongodb/mongodb-community-server:4.4.0-ubuntu2004

       

      When using the mongodb/mongodb-community-server images, rename the env vars to MONGODB_INITDB_ROOT_.... (Also, the first 'up' runs the init and then fails; so start it again without deleting the db volume)
      When using any of the 4.x images, change the mongosh to mongo in init.sh.

       

      Impact

      • I don't expect that any Devs or DevOps are counting on only the last 3-bytes to always be random. (Or at least, I hope not.) The ObjectId itself is random and that should be the only thing relied upon to not have a collision.
      • So there should almost no security implication and no impact on data integrity, etc.
      • May be more relevant to know how/why this behaviour occurs
      • Whether it's the same 3-bytes for other users or a different 3-bytes may also matter; and of course, if it occurs at all.

            Assignee:
            backlog-server-triage [HELP ONLY] Backlog - Triage Team
            Reporter:
            anirudh.dutt@gmail.com Anirudh Dutt
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: