views:

313

answers:

2

I'm currently using MongoDB to record application logs, and while I'm quite happy with both the performance and with being able to dump arbitrary structured data into log records, I'm troubled by the mutability of log records once stored.

In a traditional database, I would structure the grants for my log tables such that the application user had INSERT and SELECT privileges, but not UPDATE or DELETE. Similarly, in CouchDB, I could write a update validator function that rejected all attempts to modify an existing document.

However, I've been unable to find a way to restrict operations on a MongoDB database or collection beyond the three access levels (no access, read-only, "god mode") documented in the security topic on the MongoDB wiki.

Has anyone else deployed MongoDB as a document store in a setting where immutability (or at least change tracking) for documents was a requirement? What tricks or techniques did you use to ensure that poorly-written or malicious application code could not modify or destroy existing log records? Do I need to wrap my MongoDB logging in a service layer that enforces the write-only policy, or can I use some combination of configuration, query hacking, and replication to ensure a consistent, audit-able record is maintained?

A: 

In MongoDB 1.3.2+ you can add some restriction in user :

db.addUser("guest", "passwordForGuest", true)

But it's only existing now not better. Maybe you can add some feature request

see information in MongoDB documentation : http://www.mongodb.org/display/DOCS/Security+and+Authentication

shingara
As I mentioned in my question, I'm not looking to add a read-only user; rather, I want to add a user who can only *write* records, without being able to modify or delete them after the fact.
rcoder
+4  A: 

I would say the best bet would be to wrap up the access to MongoDB in a service layer that enforces your specific contracts. We don't do much in the way of fine-grained access control because there are so many different cases that solving all of them correctly is tricky to get right. So for the most part it's up to the application layer to implement those kind of controls.

mdirolf
That's kind of what I suspected. I'm effectively enforcing read-only access right now by not exposing a raw connection to the database anywhere in the application code. That doesn't perfectly protect us from user error or malicious updates, but I'm we'll work out another durable audit log solution.
rcoder