The planned security model for CouchDB

While CouchDB currently has no authentication or authorization facilities, a general outline of the plans exists here:

http://www.couchdbwiki.com/index.php?title=Technical_Overview#Security_and_Validation

It seems databases will have admin accounts. Full stop. No baked-in facility for user accounts. Administrators have two powers:

  1. manage design documents
  2. create other admin accounts

The Technical Overview doesn’t say, but I assume admins can also manage all documents.

Regarding non-administrative users, as I understand the plan, CouchDB will provide a rudimentary authentication delegator that accepts a login and password. “The user credentials are input to a javascript function, and the function returns a list of [reader-names] for the user, or an error if the user credentials are wrong.” I read this as meaning that the authenticating/authorizing javascript function is determined by the developer.

Write access, called “Update Validation” in the Technical Overview, is also handled dynamically by javascript: “Both the user’s credentials and the updated document are given as inputs to the validation formula, and can be used to implement custom security models…” Developers are free to implement custom authorization models, such as “author only”, where users must be listed in an author field in the document.

Read access is granted by a simplified ACL system. A CouchDB document may have a “reader list”, which specifies a list of “reader-names”. These reader-names need not correspond to user login names, so they are effectively the equivalent of groups (i.e. you can give one or more users the same reader-name). A user’s possession of a reader-name is determined by the javascript function that authenticates user logins.

Documents without a reader list are world-readable. Documents protected by reader lists are viewable only by users who possess one of the reader-names on the list. Read protection on documents applies to view results as well: “Documents that are not allowed to be read by the user are dynamically filtered out of views, keeping the document row and extracted information invisible to non-readers.”

The Technical Overview does not address this directly, but the _all_docs view must follow the same rules. That is, all unprotected documents show up in the results for all users, but protected docs only show up for users possessing the correct reader-names. The javascript functions that bind it all together will probably need administrator privileges.

Some interesting points:

  • The plans for write access allow developers to write their own authorization schemes, but the planned read access will be hard-coded to use document-based ACLs.
  • By default, document names (i.e. DocIds) are 128 bit UUIDs generated by the server. Depending on the algorithm used to generate them, these could be unguessable.
  • If the _all_docs view was not available, users would not be able to find any documents without knowledge of the (unguessable) DocIds.
  • The authentication javascript, upon success, is supposed to return a list of reader-names, but I don’t see that anything would prevent it from returning a list of DocIds.

I think we have the germ of a capability system here, even with the inflexible reader access.

Comments? Scathing refutations?

Advertisements

IRB: What was that method that greps again?

Giles Bowkett continually improves his .irbc file, and I’ve borrowed a few of those tricks. His latest is grep_methods, a helper to search for the methods available on an object. This is a very useful construct, but, as so often happens, there’s a better way baked in.


"my_arbitrary_string".methods.grep /ch/
=> ["each_byte", "match", "chomp!", "chop", "each_with_index", "chomp", "each_line", "each", "chop!"]

Lisp tutorials in Practical Common Lisp

They’re excellent. Peter Seibel’s book is available free online, as well as in print. I read enough of the free stuff to realize that I needed to stop and buy the book when I’m ready to do some projects in CL.

You can read it free here:
Common Lisp tutorial

launchd plist to run a reverse ssh tunnel

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE plist PUBLIC -//Apple Computer//DTD PLIST 1.0//EN
http://www.apple.com/DTDs/PropertyList-1.0.dtd >
<plist version='1.0'>
<dict>
<key>Label</key><string>com.automatthew.ssh_tunnel</string>
<key>UserName</key><string>matthew</string>
<key>ProgramArguments</key>
<array>
        <string>/usr/bin/ssh</string>
        <string>-nNT</string>
        <string>-R 1389:127.0.0.1:389</string>
        <string>matthew@slice1.automatthew.com</string>
</array>
<key>Debug</key><false/>
<key>Disabled</key><false/>
<key>OnDemand</key><false/>
<key>RunAtLoad</key><false/>
</dict>
</plist>

launchd plist to run a reverse ssh tunnel

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE plist PUBLIC -//Apple Computer//DTD PLIST 1.0//EN
http://www.apple.com/DTDs/PropertyList-1.0.dtd >
<plist version='1.0'>
<dict>
<key>Label</key><string>com.automatthew.ssh_tunnel</string>
<key>UserName</key><string>matthew</string>
<key>ProgramArguments</key>
<array>
        <string>/usr/bin/ssh</string>
        <string>-nNT</string>
        <string>-R 1389:127.0.0.1:389</string>
        <string>matthew@slice1.automatthew.com</string>
</array>
<key>Debug</key><false/>
<key>Disabled</key><false/>
<key>OnDemand</key><false/>
<key>RunAtLoad</key><false/>
</dict>
</plist>

"Retarded, verbose hunchback version of s-expressions"

XML, of course.

From Delusions of skill and grandeur

via Giles Bowkett