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

Secondaries are not keeping their role graphs up-to-date when admin.system.roles is updated.

XMLWordPrintableJSON

    • Type: Icon: Bug Bug
    • Resolution: Done
    • Priority: Icon: Major - P3 Major - P3
    • 2.5.4
    • Affects Version/s: 2.5.3
    • Component/s: Security
    • Labels:
      None
    • Fully Compatible
    • ALL
    • Hide
      1. Start a fresh replicaset with two members, with or without auth enabled.
      2. Use the createRole command to create a role r1 on the primary. 
        db.runCommand({createRole: "r1", roles: [], privileges: []})
      3. Look in admin.system.roles on the secondary, to show that the role data is been replicated. 
        db.getSiblingDB("admin").system.roles.find()
      4. Run the rolesInfo command on the secondary. It will not have information about the role. 
        db.runCommand({rolesInfo: "r1"})

        Expected output:

        {
	"roles" : [
		{
			"role" : "r1",
			"db" : "test",
			"roles" : [ ],
			"indirectRoles" : [ ],
			"privileges" : [ ]
		}
	],
	"ok" : 1
}

        Actual output:

        { "roles" : [ ], "ok" : 1 }
      Show
      Start a fresh replicaset with two members, with or without auth enabled. Use the createRole command to create a role r1 on the primary. db.runCommand({createRole: "r1" , roles: [], privileges: []}) Look in admin.system.roles on the secondary, to show that the role data is been replicated. db.getSiblingDB( "admin" ).system.roles.find() Run the rolesInfo command on the secondary. It will not have information about the role. db.runCommand({rolesInfo: "r1" }) Expected output: { "roles" : [ { "role" : "r1" , "db" : "test" , "roles" : [ ], "indirectRoles" : [ ], "privileges" : [ ] } ], "ok" : 1 } Actual output: { "roles" : [ ], "ok" : 1 }

      Secondaries and slaves are intended to use the logOp() hook to keep their role graphs up-to-date with replicated changes to the admin.system.roles collection. Unfortunately, secondaries and slaves are bypassing this hook during apply-ops in favor of directly calling one of the hook methods invoked by logOp().

      Proposed fix is to ensure that secondaries and slaves call logOp() just like primaries do, though they may decide to run different hook functions than the primary.

            Assignee:
            schwerin@mongodb.com Andy Schwerin
            Reporter:
            schwerin@mongodb.com Andy Schwerin
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: