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 randall.leeds@gmail.com
 designates 209.85.160.52 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAJNb-9psn5ieOsd00aXRBm09nuVBN6iXwPYQfob0rH6SSeV0JQ@mail.gmail.com>
References: 
 <CA+Y+445m_ofkwvLuB9eRnVwmAnOBR2LwQV2ZMbiARTwSCzj-ug@mail.gmail.com>
	<CAAL6JQi53Fs73aevYVd6OP3Ua2rdZyTH7PTw13rASuNTymvpOw@mail.gmail.com>
	<55B3B2E5-6FD5-4240-B171-A7768FEFD3EF@apache.org>
	<CAAL6JQigNO=eF=FcqPYnvXaK+c2Sf0uBrU1+hvqM05Z--DkQyA@mail.gmail.com>
	<DCBA4635-1F15-4777-8868-8A71E0593A77@apache.org>
	<CAAL6JQgTPREiAQ69sWrB7KqXKBNq+CKB7__T4MBB48BZ8x3j3g@mail.gmail.com>
	<CAJNb-9psn5ieOsd00aXRBm09nuVBN6iXwPYQfob0rH6SSeV0JQ@mail.gmail.com>
Date: Tue, 14 Feb 2012 11:36:26 -0800
Message-ID: 
 <CAAL6JQhz-h1eiq5-ME_QwMP4uYG0ErNAh-Zvm3zBeR42cVnTtw@mail.gmail.com>
Subject: Re: Issues blocking the 1.2.0 release
From: Randall Leeds <randall.leeds@gmail.com>
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Feb 14, 2012 at 11:06, Benoit Chesneau <bchesneau@gmail.com> wrote:
> On Tue, Feb 14, 2012 at 7:53 PM, Randall Leeds <randall.leeds@gmail.com> =
wrote:
>> On Tue, Feb 14, 2012 at 10:41, Jan Lehnardt <jan@apache.org> wrote:
>>>
>>> On Feb 14, 2012, at 19:35 , Randall Leeds wrote:
>>>
>>>> On Tue, Feb 14, 2012 at 10:19, Jan Lehnardt <jan@apache.org> wrote:
>>>>>
>>>>> On Feb 14, 2012, at 19:13 , Randall Leeds wrote:
>>>>>
>>>>>> On Tue, Feb 14, 2012 at 04:14, Noah Slater <nslater@tumbolia.org> wr=
ote:
>>>>>>> Devs,
>>>>>>>
>>>>>>> Please outline:
>>>>>>>
>>>>>>> =C2=A0 - What has been changed since round one of the 1.2.0 release
>>>>>>> =C2=A0 - What remains to be fixed for regression purposes
>>>>>>> =C2=A0 - Who is doing these fixes, and when will they be done by
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> N
>>>>>>
>>>>>> I'd like to know if it was always the case that design doc actions o=
n
>>>>>> system dbs were inaccessible to non-admins or if that's just since t=
he
>>>>>> recent security changes. If it's recent, why was that part deemed
>>>>>> necessary and can we remove it?
>>>>>
>>>>> It is part of the recent changes and the reason is that a view potent=
ially
>>>>> leaks information about docs and we don't want that. I'm happy to rel=
ax this
>>>>> later if we can convince people to write views that don't compromise =
their
>>>>> security, but until then I opted for the more secure default.
>>>>>
>>>>
>>>> I motion to remove this restriction now, unless there are actions on
>>>> the system dbs, installed by default, that leak anything at all.
>>>> I see the motivation but I feel it might be overly paranoid. Only an
>>>> admin can modify the ddocs. If a user decides to add views to
>>>> _replicator or _user they had best think about what they expose and to
>>>> whom.
>>>>
>>>> If there's no objection I can try to tackle this in the evening.
>>>
>>> I object :)
>>
>> Hmm. What's your reasoning?
> Why do you need views in _users ?
>
> - beno=C3=AEt

The idea was to make it easy to add public profiles, since
?include_docs is subject to the new security hooks, but emit() could
publish the public information.
There are valid use cases for admin-only views, which this would
prevent, though. In that case, we probably shouldn't change anything.

-R