I understand what your saying about the data being ignorant of protection. I was mostly thinking that was the easiest way to avoid per-document security from slowing down access to non-secure documents, but maybe that's not a common enough use case to be worth the problems you mentioned.
Seems like url protection and read_doc_validate() serve different purposes related to securing a publicly accessible database. Any reason not to implement both? Url protection would work for securing views, design documents, raw document access...all very needed. read_doc_validate() would add the ability to selectively secure individual documents based on both the document state and the request context ... which I think is very important too. I also wanted the ability to return modified (sanitized) versions of documents to certain users in a fairly transparent way that also can take advantage of the rest of the document and view APIs (like direct access, multi-doc and view + include_docs) I realize this could be implemented with URL protect + lists/show functions, but it could be implemented easier if read_doc_validate() was allowed to throw exception to block access or return a modified document that is the result of the read request. Another issue with respect to security ... do we need a default replication filter that can't be bypassed if its defined on that database? On Tue, Nov 30, 2010 at 7:50 AM, Bram Neijt <[email protected]> wrote: > You can not change the document during the validate_doc_update, but > you can change it if you create an _update handler[1]. You would then > firewall all direct access to the database and allow only global > access to the different views you define. Replication probably needs > access to the documents directly, so they should go behind the > firewall. > > I don't really like the idea of having a flag on the document which > has just to do with security, I think the data should be ignorant when > it comes to it's protection, as it's protection is context dependent. > > I think the biggest obstacle now is to keep people from reading > information when CouchDB is bound to a public interface. > > I would like to see the following question answered: do we want to add > a function that will set read access for the different databases (a > read_doc_validate) or do we want a module like rewrite where we get to > protect urls like we would when using a firewall (restrict > PUT/GET/DELETE and regex on url paths)? > > > Bram > > > > [1] http://wiki.apache.org/couchdb/Document_Update_Handlers > > On Mon, Nov 29, 2010 at 7:29 PM, Chad George <[email protected]> wrote: > > I was thinking the _access field would hold either a validation function > or > > (more often) a path to a function on a design document. And for that > matter, > > I'm not sure what (if anything) we gain by having the function definition > > itself on the document, just a field to point to the correct place in the > > design document should be sufficient. This way entire classes of > documents > > could share the same validation function. > > > > I don't think you can modify the document during validate_doc_update, but > it > > seems pretty easy to require the _access field to be a certain value to > > accept creating the document by the user. This would be analogous to the > > type/class of the document and could be well known without any decrease > in > > security. > > > > I was thinking that putting the "flag" that turns on document security at > > the document level would eliminate the need to run the validation > function > > for documents that don't require security, so performance should only > really > > decrease for secured systems (except for a hopefully cheap check to see > if > > the flag exists at all). > > > > Another reason to put this on the document is that it simplifies the > > validation function for lots of different document types in the same > > database. > > > > I think the view access validation function in design document is a very > > good addition to the security model as well ... possibly this could be a > > optional method defined as part of the view definition itself. > > > > > > > > On Mon, Nov 29, 2010 at 11:14 AM, Bram Neijt <[email protected]> wrote: > > > >> Yes, we could add something like _access to control access to the > >> document, however that would mean that the validate_doc_update > >> function will have to add this to the documents (you can't wait for > >> the user to add the validation function). > >> > >> That makes it seem simpler to add an access function at the database > >> level, where you would still be able to do something like > >> "if(document.type == 'should_secure') { //heavy security for the > >> document }" with the added bonus of not having to replicate your > >> security code in all your documents. > >> > >> Maybe we would be better of with a system that allows us to match > >> requests with user information, because we need something to protect > >> the view from unauthorized access as well? If somebody thinks that > >> would be a good idea, feel free to add a comment. > >> > >> Please comment on the "per document access function" vs "per database > >> access function". > >> > >> Greets, > >> > >> Bram > >> > >> On Mon, Nov 29, 2010 at 3:20 PM, Fedor Indutny <[email protected] > > > >> wrote: > >> > Yep, that's what I was talking about! > >> > > >> > 2010/11/29 Chad George <[email protected]> > >> > > >> >> Bram Neijt has recently indicated interest in working on per document > >> >> authorization. I've mentioned an idea a few times here and on the > user > >> list > >> >> but never got any real response so I'm still not sure what the > general > >> >> consensus about the idea is. > >> >> > >> >> My idea is to add a new special field on the document that indicates > a > >> >> function that can modify the document before returning it to the > user. > >> >> function(doc, req) { > >> >> /* modify doc based on req or just throw exception */ > >> >> return doc; > >> >> } > >> >> > >> >> I think the main place that document authorization is needed is > limiting > >> >> (or > >> >> sanitizing) access to raw documents. Especially in a mixed authorized > >> >> and anonymous access environment. > >> >> > >> >> Shows/Lists/Updates are already pretty easy to enforce a security > >> barrier > >> >> within a single database, but direct access to documents makes > certain > >> >> applications difficult (or impossible) to secure without a middle > server > >> >> layer. > >> >> > >> >> With a filter function attached to the document, we would have > minimal > >> >> overhead for when doc auth wasn't required so only secured documents > >> would > >> >> get any real performance penalty. By allowing the filter function to > >> return > >> >> a modified document --or-- throw an exception we could get access > denial > >> >> and > >> >> minor sanitizing with the same mechanism. > >> >> > >> >> This would work nicely with include-docs for views that need > security. > >> And > >> >> it doesn't seem that hard to keep secure info out of being embedded > in > >> >> views > >> >> and view reductions in the first place. I recently saw a suggestion > on > >> the > >> >> mailing list to have an access control function for views on the > design > >> >> document, that seems like a nice fix for securing access to views > >> >> themselves. > >> >> > >> >> - Chad > >> >> > >> > > >> > > >> > > >> > -- > >> > Cheers, > >> > Fedor Indutny. > >> > > >> > Skype: fedor.indutny > >> > Gtalk: [email protected] > >> > Github: http://github.com/donnerjack13589 > >> > > >> > > >
