Mongo Roles in 2.6, Incongruent description.

I'm reading the documentation on Mongo's role based authorization for Mongo 2.6 - http://docs.mongodb.org/manual/core/authorization/. The documentation states that roles have a database, and a set of privileges. Yet privileges are a pair <action, resource>, where can be a database. This creates a (at least conceptual) conflict that is not resolved in the documentation. In particular:

  1. What is the purpose of the database field of a role? Why is it there at all? The docs a fond of saying roles are created 'on" databases, yet they are stored in admin.system.roles.
  2. How are conflicts between the database of a role and the privileges of a role resolved? Are allowed to conflict at all? What the rules?

As far as I can gather, in 2.6, only roles defined "on" the admin database can grant privileges to other databases? This seems to be consistent with 2.4. But its all quite confusing for mongo newbs like me.




I can see how this might be a bit convoluted.

This page http://docs.mongodb.org/manual/reference/resource-document/#resource-document might help - it discusses when defining resource for a role how it may interact with the scope it's granted on.

The following note may clarify:

"When granted a role, a user receives all the privileges of that role. A user can have several roles concurrently, in which case the user receives the union of all the privileges of the respective roles."

Also note:

"For a user-defined role scoped for a non-admin database, the resource specification for its privileges must specify the same database as the role. User-defined roles scoped for the admin database can specify other databases."

So the role database is "higher level" specification of scope, where the privilege is the more granular specification of actions allowed on resource.  http://docs.mongodb.org/manual/reference/privilege-actions/

You cannot define a role with privileges that apply to resource outside of the resource that it's granted on.

"Roles always grant privileges and never limit access. For example, if a user has both read and readWriteAnyDatabase roles on a database, the greater access prevails."

I think you should simply ignore the issue of where roles are stored - that is simply an implementation detail and is not related to the scope of the role at all.