Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of jchris@gmail.com designates
 209.85.210.199 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:content-type;
        b=rExCeDicURCCcGxr8p1FZ1EjJRjiH+MI7lm8YAAPiOAHpcrfUV06sOcnQs8X6aWUir
         Za+DPeXx6CV7lEFOArzYg0Ie8rwQbrFDj999bJ82mD+aHmMtYoTwTLfRQbU785k9oqsk
         BndRd4j2Z2xaWt/W/tuZ+9kqlwYh7SRe5D8ec=
MIME-Version: 1.0
Sender: jchris@gmail.com
In-Reply-To: <20100209100419.GB5270@uk.tiscali.com>
References: <e282921e1002030921g53af1711r3b46ebe31f4cb38b@mail.gmail.com>
	 <015a01caa529$3d24e230$b76ea690$@com>
	 <2C591A9F-55E4-49DD-A3E3-9BA075EAE633@apache.org>
	 <20100205224225.GA8463@uk.tiscali.com>
	 <20100206095856.GA5057@uk.tiscali.com>
	 <e282921e1002061052t6b58a416h8ac75513a9c0f839@mail.gmail.com>
	 <20100207091927.GA4771@uk.tiscali.com>
	 <20100208161946.GA6227@uk.tiscali.com>
	 <20100209100053.GA5270@uk.tiscali.com>
	 <20100209100419.GB5270@uk.tiscali.com>
Date: Tue, 9 Feb 2010 09:04:49 -0800
Message-ID: <e282921e1002090904i3aca02b8vd34ad10f9431a6a7@mail.gmail.com>
Subject: Re: DB ACLs (was Re: 0.11 Release / Feature Freeze for 1.0)
From: Chris Anderson <jchris@apache.org>
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Feb 9, 2010 at 2:04 AM, Brian Candler <B.Candler@pobox.com> wrote:
> On Tue, Feb 09, 2010 at 10:00:53AM +0000, Brian Candler wrote:
>> Even going back to Admin Party it doesn't work:
>>
>> $ curl -X POST -d '{"map":"function(doc) {}"}' http://127.0.0.1:5984/briantest/_temp_view
>> {"error":"unauthorized","reason":"You are not authorized to access this db."}
>>
>> However I'm a bit perplexed as to why view_errors.js in the test suite is
>> still passing.
>
> I can see now. I had a non-empty _readers list, and for some reason this was
> preventing even system-level-admin or admin party mode from accessing
> _temp_view. Removing this resource made it work.

If you do a get against /_session does it show you as an admin?

couch_db:check_is_admin() should allow access in this case.

If you can reliably reproduce this, I'd like to fix it.

>
> $ curl http://127.0.0.1:5984/briantest/_readers
> {"names":["brian","brianadmin"],"roles":[]}
>
> $ curl http://127.0.0.1:5984/briantest/_admins
> {"names":["brianadmin"],"roles":[]}
>
> $ curl -d '{}' -X PUT http://127.0.0.1:5984/briantest/_readers
> {"ok":true}
>
> $ curl -X POST -d '{"map":"function(doc) { emit(JSON.stringify(123,null)); }"}' http://127.0.0.1:5984/briantest/_temp_view
> {"total_rows":0,"offset":0,"rows":[]}
>


-- 
Chris Anderson
http://jchrisa.net
http://couch.io