Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: 
 <CAAL6JQgUDtZ6M_NZM3a-Rc1DxFJPTwL4bMzW_fEASAPg45+yew@mail.gmail.com>
References: <111A4F0F-6055-435B-8FF9-8D48CC058E4D@apache.org>
 <CAN-3CBLe1Moe0ot_hyyrh1ydFowdmTmDz80UkOAfKNcgNhTeRw@mail.gmail.com>
 <F7EB94AD-E664-4221-93F1-F123E40A6D6F@apache.org>
 <CAN-3CBJ__jyS7rqdUOPjtL+0czFcfsfLX_3JbJrjJt6n1cUmMQ@mail.gmail.com>
 <CABvT1DFdrNVKv43Y1KKH-0p+AzK35z-Zh_M81BAK0mRfbsQq-g@mail.gmail.com>
 <CAJNb-9q=R6rv-VaY-auxEr38E8kT1wLoGoPHNjE6UUkkNFDMjQ@mail.gmail.com>
 <CABvT1DFLxnESJR7YSXpR6vEuwF-nsOD14BacWt11JzJXDeEbOg@mail.gmail.com>
 <CAAL6JQiYkRrryo9Os2JE1Wrzx5D5TkO2tv76MmLkgJzQakGTWQ@mail.gmail.com>
 <CAEyAqDvf=hTAW3FNsjUQQWppX2jHuZSN52rgB=LoEwc+uMnvyg@mail.gmail.com>
 <CAJ_m3YCisGaHa2PpJ4oTD6XMRmM3dJ+vqsMfFtH_zaObEXJRnw@mail.gmail.com>
 <CAEyAqDue1=4tq13CM535_q+2zpXmqK8KC_AFqKETvag6a4GqMw@mail.gmail.com>
 <CAJ_m3YA+4F7MiecX-pCEgVSJ-642LMOy-eC7avhzoHc8hp3img@mail.gmail.com>
 <CAN-3CBK3_8S=J=gMBDpBGKwj+Gyv6bt55pcicKaU3dMugeOZcg@mail.gmail.com>
 <CAEyAqDv+W-987N790JOLb=dNW1UpPeN2aeRFeG10qsOhjPQXEg@mail.gmail.com>
 <CAAL6JQiSut=WWYS_vHvpvcOefAPhrgmvbd+SFpuJfcxf9nhwfg@mail.gmail.com>
 <CAJ_m3YCXqCd_8Xn90XfTdAXOzGoP=THufk3XR_ia4oHr+n5JGw@mail.gmail.com>
 <CAAL6JQgUDtZ6M_NZM3a-Rc1DxFJPTwL4bMzW_fEASAPg45+yew@mail.gmail.com>
From: Jason Smith <jhs@iriscouch.com>
Date: Sat, 27 Aug 2011 10:01:51 +0700
Message-ID: 
 <CAN-3CBKVQiM_=eNBkD4w=1QUeycBODZESKLnyz95Bdk29L0aLg@mail.gmail.com>
Subject: Re: The _security object should be versioned
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=UTF-8

On Sat, Aug 27, 2011 at 9:09 AM, Randall Leeds <randall.leeds@gmail.com> wrote:
>> The issue here is that adding a revision tree most likely means a
>> requirement that the HTTP API changes to use MVCC tokens.
>
> _local docs already do. They just don't support ?new_edits, or
> revs_info/revs/open_revs/meta, though I'd have to check.. It's not a hard
> requirement that we support this stuff. And certainly the old /_security
> endpoint could completely paper over this if we just make it clobber (which
> no one on vanilla couch should care about).

I propose there is no more /_security HTTP endpoint.

Instead, _local docs get full MVCC support. You can post conflicts
with ?new_edits=false and resolve them normally. The API becomes
smaller and also more consistent.

Next, _local/security is special to CouchDB. Upon an update, the
current winning revision is cached in the DB header. This allows couch
to quickly confirm read or admin permission when using the DB, and
send secObj to validate_doc_update.

Does this sound reasonable? I see two bonuses:

1. Full MVCC for _local would be nice for users, who are using _local
more. If it's worth storing, it's worth storing in MVCC.
2. Design docs can validate the security policy.

I can think of two issues:

1. Does this require updating the replicator to update _local docs correctly?
2. Only admins can change _security. But anybody with read access can
change _local/*. Does couch special-case _local/security?

-- 
Iris Couch