标签：
Every database includes the following client roles:
Provides the ability to read data on all non-system collections and on the following system collections:system.indexes, system.js, and system.namespaces collections. The role provides read access by granting the following actions:
Provides all the privileges of the read role plus ability to modify data on all non-system collections and the system.js collection. The role provides the following actions on those collections:
Every database includes the following database administration roles:
Provides the following actions on the database’s system.indexes, system.namespaces, andsystem.profile collections:
Changed in version 2.6.4: dbAdmin added the createCollection for the system.profilecollection. Previous versions only had the dropCollection on the system.profile collection.
Provides the following actions on all non-system collections. This role does not include full read access on non-system collections:
dropCollection and createCollection on system.profile only
The database owner can perform any administrative action on the database. This role combines the privileges granted by the readWrite, dbAdmin and userAdmin roles.
Provides the ability to create and modify roles and users on the current database. This role also indirectly provides superuser access to either the database or, if scoped to the admin database, the cluster. TheuserAdmin role allows users to grant any user any privilege, including themselves.
The userAdmin role explicitly provides the following actions:
The admin database includes the following roles for administering the whole system rather than just a single database. These roles include but are not limited to replica set and sharded cluster administrative functions.
Provides the greatest cluster-management access. This role combines the privileges granted by theclusterManager, clusterMonitor, and hostManager roles. Additionally, the role provides thedropDatabase action.
Provides management and monitoring actions on the cluster. A user with this role can access the configand local databases, which are used in sharding and replication, respectively.
Provides the following actions on the cluster as a whole:
Provides the following actions on all databases in the cluster:
On the config database, provides the following actions on the settings collection:
On the config database, provides the following actions on all configuration collections and on thesystem.indexes, system.js, and system.namespaces collections:
On the local database, provides the following actions on the replset collection:
Provides read-only access to monitoring tools, such as the MongoDB Cloud Manager and Ops Managermonitoring agent.
Provides the following actions on the cluster as a whole:
Provides the following actions on all databases in the cluster:
Provides the find action on all system.profile collections in the cluster.
Provides the following actions on the config database’s configuration collections andsystem.indexes, system.js, and system.namespaces collections:
Provides the ability to monitor and manage servers.
Provides the following actions on the cluster as a whole:
Provides the following actions on all databases in the cluster:
The admin database includes the following roles for backing up and restoring data:
Provides minimal privileges needed for backing up data. This role provides sufficient privileges to use theMongoDB Cloud Manager backup agent, Ops Manager backup agent, or to use mongodump to back up an entire mongod instance.
Provides the following actions on the mms.backup collection in the admin database:
Provides the listDatabases action on the cluster as a whole.
Provides the listCollections action on all databases.
Provides the listIndexes action for all collections.
Provides the find action on the following:
To back up the system.profile collection, which is created when you activate database profiling, you must have additional read access on this collection. Several roles provide this access, including theclusterAdmin and dbAdmin roles.
all non-system collections in the cluster
all the following system collections in the cluster: system.indexes, system.namespaces, and system.js
the admin.system.users and admin.system.roles collections
legacy system.users collections from versions of MongoDB prior to 2.6
Provides minimal privileges needed for restoring data from backups. This role provides sufficient privileges to use the mongorestore tool to restore an entire mongod instance.
Provides the following actions on all non-system collections and system.js collections in the cluster; on the admin.system.users and admin.system.roles collections in the admin database; and on legacy system.users collections from versions of MongoDB prior to 2.6:
Provides the listCollections action on all databases.
Provides the following additional actions on admin.system.users and legacy system.userscollections:
Provides the find action on all the system.namespaces collections in the cluster.
Although, restore includes the ability to modify the documents in the admin.system.userscollection using normal modification operations, only modify these data using the user management methods.
The admin database provides the following roles that apply to all databases in a mongod instance and are roughly equivalent to their single-database equivalents:
Provides the same read-only permissions as read, except it applies to all databases in the cluster. The role also provides the listDatabases action on the cluster as a whole.
Provides the same read and write permissions as readWrite, except it applies to all databases in the cluster. The role also provides the listDatabases action on the cluster as a whole.
Provides the same access to user administration operations as userAdmin, except it applies to alldatabases in the cluster. The role also provides the following actions on the cluster as a whole:
The role also provides the following actions on the admin.system.users andadmin.system.roles collections on the admin database, and on legacy system.userscollections from versions of MongoDB prior to 2.6:
Changed in version 2.6.4: userAdminAnyDatabase added the following permissions on theadmin.system.users and admin.system.roles collections:
The userAdminAnyDatabase role does not restrict the permissions that a user can grant. As a result,userAdminAnyDatabase users can grant themselves privileges in excess of their current privileges and even can grant themselves all privileges, even though the role does not explicitly authorize privileges beyond user administration. This role is effectively a MongoDB system superuser.
Provides the same access to database administration operations as dbAdmin, except it applies to alldatabases in the cluster. The role also provides the listDatabases action on the cluster as a whole.
Several roles provide either indirect or direct system-wide superuser access.
The following roles provide the ability to assign any user any privilege on any database, which means that users with one of these roles can assign themselves any privilege on any database:
dbOwner role, when scoped to the admin database
userAdmin role, when scoped to the admin database
userAdminAnyDatabase role
The following role provides full privileges on all resources:
Provides access to the operations and all the resources of the readWriteAnyDatabase,dbAdminAnyDatabase, userAdminAnyDatabase and clusterAdmin roles combined.
root does not include any access to collections that begin with the system. prefix.
For example, without the ability to insert data directly into the:data:system.users <admin.system.users>and system.roles collections in the admin database. root is not suitable for writing or restoring data that have these collections (e.g. with mongorestore.) To perform these kinds of restore operations, provision users with the restore role.
MongoDB assigns this role to user objects that represent cluster members, such as replica set members and mongos instances. The role entitles its holder to take any action against any object in the database.
Do not assign this role to user objects representing applications or human administrators, other than in exceptional circumstances.
If you need access to all actions on all resources, for example to run applyOps commands, do not assign this role. Instead, create a user-defined role that grants anyAction on anyResource and ensure that only the users who need access to these operations have this access.
标签：
原文地址：http://my.oschina.net/imhaha/blog/509092
