[SERVER-9274] How to recover prvilege from read-only to read-write for admin user Created: 08/Apr/13  Updated: 11/Jul/16  Resolved: 23/Apr/13

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

Type: Question Priority: Critical - P2
Reporter: zijian_he Assignee: Spencer Brody (Inactive)
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OS version:redhat linux 5.6
kernel version:2.6.18-238.el5
MongoDB version:2.0.2-rc1


Participants:

 Description   

I have set up the MongoDB Replica Set,I startup the mongod instance using KeyFile parameter,I also create user "root" in admin database,grant the user privilege read-write.
But I have incidently change the user's "root" privilege from read-write to read-only.
My question is how to recover the privlege from read-only to read-write?



 Comments   
Comment by zijian_he [ 23/Apr/13 ]

Thank you for your reply.I have no more further questions.

----邮件原件----
发件人: Spencer Brody (JIRA) jira@mongodb.org
发送时间: 2013年4月22日 23:07
收件人: Paul 何子健
主题: [MongoDB-JIRA] (SERVER-9274) How to recover prvilege from read-only to read-write for admin user

[ https://jira.mongodb.org/browse/SERVER-9274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Spencer Brody updated SERVER-9274:
----------------------------------

Status: Resolved (was: Waiting For User Input)
Fix Version/s: (was: debugging with submitter)
Resolution: Gone away

I'm resolving this ticket due to inactivity. Feel free to re-open if you have further questions.


This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
DISCLAIMER: This email and any files transmitted with it are intended for the named recipient(s) only. It may contain confidential, proprietary or legally privileged information. If you are not the intended recipient(s), please immediately delete it and you should not read, print, re-transmit or act in reliance on any of the contents of this e-mail. This email has been swept by a virus software product for the presence of computer viruses. LKK Health Products Group Ltd and its affiliates will not be liable as a result of any computer virus being passed on.

—— LKK Health Products Group Ltd

声明:该邮件及附带的任何文件只供指定收件人参阅,它可能包含了机密、私密或者受到法律保护的信息。如果你是非指定收件人,请即刻删除该邮件,并不应阅读、复印、转发和不得使用该邮件资料作任何用途。该邮件在发出前经过电脑病毒扫描。李锦记健康产品集团及其附属机构不对电脑病毒传播承担任何责任。

——李锦记健康产品集团

Comment by Spencer Brody (Inactive) [ 22/Apr/13 ]

I'm resolving this ticket due to inactivity. Feel free to re-open if you have further questions.

Comment by Spencer Brody (Inactive) [ 09/Apr/13 ]

Unfortunately there is no way change between a secured and unsecured system without downtime.

From your last comment, I assume this replica set in question is a shard as part of a sharded deployment? When you say you have a read-only admin user, are you referring to an admin user of the whole sharded system, added through mongos, or of a specific shard, created by directly connecting to the primary of the shard? Whenever you are writing data to a sharded system, you should always go through mongos - you should never write data by directly connecting to a shard, so if you are saying that your shard's admin user is read-only, that's probably fine so long as you have a read-write admin user for the whole sharded system that can be authenticated to through mongos.

Comment by zijian_he [ 09/Apr/13 ]

During restarting the whole replica set,whether the rest of replica set can still provide the service?
Whether I should also shutdown the route server and config server to prevent the user access the mongo Replica Set?

Comment by Spencer Brody (Inactive) [ 08/Apr/13 ]

Assuming you have no other read-write admin users to use to update the "root" user's privilege document, then you'll have to restart your whole replica set without --auth or --keyFile, update the user definition while the system has access control checks disabled, and then restart the replica set again to re-enable --keyFile.

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