[SERVER-40434] Root user can't delete minOpTimeRecovery from admin.system.version Created: 02/Apr/19  Updated: 09/Apr/19  Resolved: 02/Apr/19

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

Type: Bug Priority: Major - P3
Reporter: Fushan Chen Assignee: Danny Hatcher (Inactive)
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Documented
is documented by DOCS-12592 Restoring from Sharded Collection ins... Closed
Operating System: ALL
Steps To Reproduce:

https://docs.mongodb.com/v3.6/tutorial/restore-sharded-cluster/#remove-the-minoptimerecovery-document-from-the-admin-system-versions-collection

Participants:

 Description   

I tried to follow steps in https://docs.mongodb.com/v3.6/tutorial/restore-sharded-cluster/#d-restore-each-shard-replica-set

to restore a 3.6 sharded cluster.

I got stuck on this step, with error:

WriteCommandError({
	"ok" : 0,
	"errmsg" : "not authorized on admin to execute command { delete: \"system.version\", ordered: true, lsid: { id: UUID(\"2da72adc-460e-4efd-90a4-80465b219566\") }, $db: \"admin\" }",
	"code" : 13,
	"codeName" : "Unauthorized"
})

This happened even when I granted my root/admin user with 'readWrite' or 'restore' roles. I was able to delete this document only after I granted it with '__system' role, which is not a recommended practice.

I haven't seen any discussion about this problem in mongodb documentation or on the internet.

Is there anything I'm missing here?

 



 Comments   
Comment by Danny Hatcher (Inactive) [ 09/Apr/19 ]

fchen, we intentionally limit access to most system collections to prevent users from accidentally breaking their system. We have in the past granted some privilege to select namespaces but only when there is no realistic alternative. Going forward, I believe we are going to add the instructions to disable authentication for that step which would avoid the problem all together. However, we will keep an eye on this collection and if we need to access it for other procedures, we may provide access to it via a role in the future.

Thanks,

Danny

Comment by Fushan Chen [ 02/Apr/19 ]

Thanks Danny.

It's probably not just a documentation miss. Actually I can't find a proper role/privilege other than the unrecommended "__system" role that has the permission to run the instructed step.

Comment by Danny Hatcher (Inactive) [ 02/Apr/19 ]

Hello,

Thanks for the report! I believe this to be a documentation error so I have opened DOCS-12592 to address it. Please follow that ticket for updates.

Thanks,

Danny

Generated at Thu Feb 08 04:54:58 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.