[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: |
|
||||||||
| Operating System: | ALL | ||||||||
| Steps To Reproduce: | |||||||||
| 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:
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 Thanks, Danny |