[SERVER-1105] access control per collection Created: 08/May/10 Updated: 30/Oct/15 Resolved: 11/Oct/13 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Security |
| Affects Version/s: | None |
| Fix Version/s: | 2.5.3 |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | derlok epsilon | Assignee: | Andy Schwerin |
| Resolution: | Done | Votes: | 61 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||
| Description |
|
I recently started using mongodb in depth and I was surprised to find that this does not have an access control per collection. from the security point of view this point is of great importance and is an impediment to migrate from sql to nosql in production. I really believe that this feature should be included as soon as possible or at least have a higher priority. thank you very much |
| Comments |
| Comment by Andy Schwerin [ 11/Oct/13 ] |
|
Documentation in conjunction with User Defined Roles ( |
| Comment by auto [ 26/Sep/13 ] |
|
Author: {u'username': u'andy10gen', u'name': u'Andy Schwerin', u'email': u'schwerin@10gen.com'}Message: Once we've created appropriate system roles for dump and restore, we can revisit |
| Comment by auto [ 26/Sep/13 ] |
|
Author: {u'username': u'andy10gen', u'name': u'Andy Schwerin', u'email': u'schwerin@10gen.com'}Message: Also requires changing the privileges of the built-in roles. This patch takes the opportunity to remove the 2.2-style read-only roles in favor of the 2.4-style "read" and "readAnyDatabase" roles, and renames the 2.2-style read-write roles "dbOwner" and "root". The "root" name, at least, is subject to change prior to the next unstable release. Test harnesses are updated as needed to use the correct builtin roles. |
| Comment by auto [ 23/Sep/13 ] |
|
Author: {u'username': u'andy10gen', u'name': u'Andy Schwerin', u'email': u'schwerin@10gen.com'}Message: |
| Comment by auto [ 23/Sep/13 ] |
|
Author: {u'username': u'andy10gen', u'name': u'Andy Schwerin', u'email': u'schwerin@10gen.com'}Message: This patch has two principal components. First, it changes the interface to Privilege and |
| Comment by auto [ 20/Sep/13 ] |
|
Author: {u'username': u'andy10gen', u'name': u'Andy Schwerin', u'email': u'schwerin@10gen.com'}Message: |
| Comment by auto [ 20/Sep/13 ] |
|
Author: {u'username': u'andy10gen', u'name': u'Andy Schwerin', u'email': u'schwerin@10gen.com'}Message: Also, beef up privilege_document_parser_test, instead of testing role parsing in The role->privilege mapping belongs to the RoleGraph, and the authorization of actions |
| Comment by Daniel Pasette (Inactive) [ 25/Jul/13 ] |
|
justanyone, as indicated by the fixVersion of 2.5.2, per-collection access control is also planned for the 2.6 release along with some other nice security enhancements like user-defined roles ( |
| Comment by Tahir [ 19/Jul/13 ] |
|
Good to hear that Dan. |
| Comment by Kevin J. Rice [ 19/Jul/13 ] |
|
1. Let's solve basic problems before moving on to advanced features like permissions per field. 2. None/Read-only/Read-Write perms per database is a basic feature, methinks. 3. Per-Collection is next, that's table-level control, and it pretty basic as well. 4. Field level seems pretty advanced to me. Yes, Oracle has it (and probably all the majors - DB2, Sybase, Postgres, etc.). But, see #1 above. Notes from the 'competition' (Oracle docs): "You can grant privileges to use the DELETE, INSERT, SELECT, and UPDATE DML operations on a table or view. Grant these privileges only to users and roles that need to query or manipulate data in a table. You can restrict INSERT and UPDATE privileges for a table to specific columns of the table. With selective INSERT, a privileged user can insert a row with values for the selected columns. All other columns receive NULL or the default value of the column. With selective UPDATE, a user can update only specific column values of a row. Selective INSERT and UPDATE privileges are used to restrict user access to sensitive data. For example, if you do not want data entry users to alter the salary column of the employees table, then selective INSERT or UPDATE privileges can be granted that exclude the salary column. Alternatively, a view that excludes the salary column could satisfy this need for additional security." |
| Comment by Daniel Pasette (Inactive) [ 18/Jul/13 ] |
|
noobcodeur, we are planning on adding a feature to the aggregation framework in 2.6 ( |
| Comment by Tahir [ 18/Jul/13 ] |
|
Yes, for writes... but it's not flexible enough.. in a general fashion I might want to send only the readable fields from the dB object as JSON response without much intricacies for instance. read access restrictions at the field level would facilitate that without much hassle. And I think it would be faster if implemented as an option for instance than if done at the application level. |
| Comment by Artem [ 17/Jul/13 ] |
|
@Tahir I think you can do that at application level. You can check field by $exists operator. If not exists then write, otherwise don't |
| Comment by Tahir [ 16/Jul/13 ] |
|
@Artem yes that is what I was thinking about. |
| Comment by Artem [ 16/Jul/13 ] |
|
@Tahir maybe you want read-only field? I mean to be possible write once. |
| Comment by Tahir [ 16/Jul/13 ] |
|
I don't. And I meant it as an option. Just like you would not index every field. Someone might want to restrict access to a particular field. But honestly I don't know what it would imply in terms of performance. Do you ? |
| Comment by Alex Mcauley [ 16/Jul/13 ] |
|
@Tahir: Field level is the MOST idiotic idea ever, do you know how much performance the DB would lose to achieve that? |
| Comment by Tahir [ 15/Jul/13 ] |
|
Why restrict to collection level ? I would like to be even more granular, field level. |
| Comment by derlok epsilon [ 14/Jan/13 ] |
|
Esto es vergonzoso. 3 años y un pedido de seguridad importante sigue sin tener respuesta. Esta claro que esta solución no esta preparada para ambiente productivos serios. gracias por nada. |
| Comment by bad ninja [ 17/Dec/12 ] |
|
Sounds like database-level access control is not granular enough. I'm in the same boat. +1 Also, prioritizing on # of votes is not a good metric to use to drive your release cycles. Instead, you should talk about it internally and see if it makes sense as a business strategy. If the answer is no, then that's fine - just tell us that and we'll look at other solutions. However, relying on a magical number to be hit before starting a discussion doesn't take in account the number of people who want the feature and didn't vote (for whatever reason - maybe they don't want to create a login, etc.), and the other way around - it may falsely represent a large number of requests if someone is determined to create a bunch of different logins and masquerade as different users to get what they want. Thx. |
| Comment by ken eucker [ 16/Jul/12 ] |
|
Jumping in on the conversation here: I have started a project that hinges on micro level security for users and really need options with Mongo in order to implement it. Being able to set security on stored javascript, collections, and fields would allow me to move my project further with Mongo. Until then, I can't use it like I need to. |
| Comment by sam king [ 29/May/12 ] |
|
I have a startup which focuses on secure messaging from within social networks in which I added the per collection role base access control. But I haven't had the time to have it reviewed and check back to the source, I hope to find some time to give it back that next month. |
| Comment by derlok epsilon [ 29/May/12 ] |
|
C'mon guys, when are you going to consider this request? |
| Comment by David Hoyt [ 25/Feb/12 ] |
|
+1 to what everyone else has said. |
| Comment by Eliot Horowitz (Inactive) [ 09/Feb/12 ] |
|
read vs read/write per database exists today. |
| Comment by Jon Rista [ 09/Feb/12 ] |
|
My team has recently started using MongoDB. The issue of security did not enter our minds until we started to run our projects through QA, who wanted direct query access to validate data. I think its essential to security and reliability of data that ACL's be added per-database and per-collection, with the ability to restrict access to read-only, read/write, read/write/delete, etc. A fine grain of control will greatly expand the viability of MondoDB in the enterprise. |
| Comment by Andrew Morrow (Inactive) [ 12/Jan/12 ] |
|
My team as well would like per-database / per-collection level ACLs. We have separate project teams that handle sensitive data, and we would like to be able to ensure that different teams cannot view or delete each others data on a shared mongodb installation. Creating multiple independent mongodb installations is not realistic. |
| Comment by Wim Wisselink [ 23/Dec/11 ] |
|
As a webdevelopment company we developed a CMS which has MongoDB as it's main DB. Now serving a lot of website it's unfeasible to use the same username and password to authenticate with the db. I really hope this feature passes. |
| Comment by Soumyajit Bhattacharjee [ 02/Nov/11 ] |
|
Kindly implement this feature as soon as you can because its very important for security-critical use cases. Since a model based on one db per user will unnecessarily waste space in preallocation.. I'm working on a system where the data stored by users shud not be accessible to developers and admins. currently using a single db with a single user, but to implement the security requirement we need a user-to-collection authentication framework... Thanks |
| Comment by kursion [ 16/Sep/11 ] |
|
Yeah that would be nice. Imagine you have multiple websites on ONE server... you actually need to run multiple instance of Mongo to separate every architecture. Would be nice to have some "folder" where you put every db that are link to a website (with an access/permissions for it). MySQL does for example but it's not noSQL |
| Comment by Nick Daugherty [ 06/May/11 ] |
|
This feature would be extremely useful and I think it's a must have for many companies before they get behind Mongo. |
| Comment by Colin Watson [ 26/Jul/10 ] |
|
Lack of highly granular access controls will limit adoption. We were hoping to use MongoDB, but as a minimum would need multiple roles (e.g. public, authenticated user, system, logging, administrator) so we could partition access to the data based on what we know about the user. These roles would then have different abilities to add, edit, delete data in various collections. |
| Comment by Justin Dearing [ 05/Jul/10 ] |
|
@shimon, Your suggestions are good, but probably belong in a separate ticket. |
| Comment by Shimon Doodkin [ 05/Jul/10 ] |
|
i want to give paritial access to the data in a table like let read only with a query of owner_user=i_define_it_ statically_or_dynamically _on_logon_or_else or another model is to make a permissions function per user that will check every query and return ok or kind of like this. or define a structure of restrictions some of them static some of them dynamic- function settings={ , , ]}, :['onupdate',function(collection,col,user,op,where,data) { if(data['userid']==false) return false; else return true}]}, ]}, } } or a function that returns this and generates this dynamically. |
| Comment by derlok epsilon [ 09/May/10 ] |
|
The ideal would add this feature to the existing mongodb's authentication . Currently we can define authorized users and giving them rw or read-only permissions. In my opinion, if this same feature gives us a higher level of specification, if we could defined write access or read-only users permission per collection this would allow to set users roles access for the proper segregation of duties. [sorry for my english] |
| Comment by Justin Dearing [ 08/May/10 ] |
|
A more robust security model for mongo would make it useful for direct querying. This should be carefully planned before implementing. A few things to think about: What about stored javascript? In SQL server, if you have permission to execute a stored proc, but not the tables it manipulates, the stored proc will run. In postgres this is not the case, unless you explicitly declare a "sudo user" for the stored proc to run as. Since stored javascript is stored in a system collection, then it might make sense to add document level permissions. |
| Comment by Eliot Horowitz (Inactive) [ 08/May/10 ] |
|
This is the first request we've gotten for this. |