[SERVER-19191] "restore" role does not have applyOps permissions on servers using a keyFile Created: 29/Jun/15  Updated: 05/Apr/17  Resolved: 17/Oct/16

Status: Closed
Project: Core Server
Component/s: Security
Affects Version/s: 2.6.10, 3.0.4
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Kyle Erf Assignee: Spencer Jackson
Resolution: Duplicate Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Documented
is documented by DOCS-6253 Describe authz exception for mongores... Closed
Duplicate
is duplicated by SERVER-25994 Allow applyOps to validate authorizat... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Steps To Reproduce:

mongod --fork --dbpath data --logpath data/mongod.log --keyFile test-keyfile
mongo localhost/admin --quiet --eval 'db.createUser({user: "admin", pwd: "pass", roles: ["restore"]})'
 
mongo -u admin -p pass --authenticationDatabase admin
db.runCommand({ applyOps: [ { ts: Timestamp(142,455), h: 5831926941336282060, v: 2, op: "i", ns: "ccc.foo", o: { _id: ObjectId('54f7dfcad3b3588e91541cdf'), x: 747.0 }, o2: {} }]})
{
  "ok": 0,
  "errmsg": "not authorized on test to execute command { applyOps: [ { ts: Timestamp 142000|455, h: 5.831926941336282e+18, v: 2.0, op: \"i\", ns: \"ccc.foo\", o: { _id: ObjectId('54f7dfcad3b3588e91541cdf'), x: 747.0 }, o2: {} } ] }",
  "code": 13
}

If you restart the server without a keyFile, the same user will be able to successfully run the applyOp.

Sprint: Security 6 07/17/15, Security 9 (09/18/15)
Participants:

 Description   
Issue Status as of Jul 14, 2015

ISSUE SUMMARY
The restore role does not provide users access to the applyOps command, which mongorestore uses with the --oplogReplay option.

USER IMPACT
mongorestore --oplog will not apply oplog entries captured during the mongodump operation, and exit with an error when attempting to use mongorestore with the restore role and a MongoDB deployment that uses access control. For additional information, please review the documentation on the restore role

WORKAROUNDS
To restore data using the mongorestore --oplogReplay option, users may create a role that grants anyAction on anyResource. Do not assign this role to any other user. This role provides full unrestricted access to the system.

Alternatively users can disable authentication while restoring data by starting mongod instances without the --auth option during the installation and then re-enabling --auth after completing the restoration.

Original description

This edge case breaks mongorestore --oplogReplay on 2.6 and 3.0 systems using auth and keyFile together.

When using a shell as a user with the restore role, you should always be able to run an applyOps command, as these are essential to mongorestore jobs. Running applyOps as a restore user works on a mongod instance running without keyFile, however, if you restart the sever with a --keyFile file option, the same user will not be able to run the command successfully. The server returns

Failed: restore error: error applying oplog: applyOps: not authorized on admin to execute command { applyOps: [ {...} ] }

Note that when using a user with the __system role, applyOps will work in both cases.



 Comments   
Comment by Spencer Jackson [ 17/Oct/16 ]

I have tested this again on 3.3, after the work done in SERVER-25994. Running the command sequence provided as the reproduction steps results now results in:

{
        "applied" : 1,
        "code" : 26,
        "codeName" : "NamespaceNotFound",
        "errmsg" : "Failed to apply insert due to missing collection: { ts: Timestamp 142000|455, h: 5.831926941336282e+18, v: 2.0, op: \"i\
", ns: \"ccc.foo\", o: { _id: ObjectId('54f7dfcad3b3588e91541cdf'), x: 747.0 }, o2: {} }",
        "results" : [
                false
        ],
        "ok" : 0
}

Running ``db.createCollection("foo")``` from the 'ccc' database, and running the applyOps command results in:

{ "applied" : 1, "results" : [ true ], "ok" : 1 }

I will now close this ticket.

Comment by Andreas Nilsson [ 15/Jul/15 ]

We have reproduced the problem and --oplogReplay and auth does not play well together. The reason is that --oplogReplay uses applyOps which requires universal privileges on the system.

We're going to try to rewrite the applyOps permission check to be more granular to the actual operations that are to be performed. Before applying the requested operations we will refactor the authorization check to loop through the list of operations and perform individual authorization checks on each one of them.

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