couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randall Leeds <randall.le...@gmail.com>
Subject Re: Issues blocking the 1.2.0 release
Date Tue, 14 Feb 2012 19:40:21 GMT
On Tue, Feb 14, 2012 at 11:05, Jan Lehnardt <jan@apache.org> wrote:
>
> On Feb 14, 2012, at 19:53 , Randall Leeds 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>
wrote:
>>>>>>> Devs,
>>>>>>>
>>>>>>> Please outline:
>>>>>>>
>>>>>>>   - What has been changed since round one of the 1.2.0 release
>>>>>>>   - What remains to be fixed for regression purposes
>>>>>>>   - 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
on
>>>>>> system dbs were inaccessible to non-admins or if that's just since
the
>>>>>> 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 potentially
>>>>> leaks information about docs and we don't want that. I'm happy to relax
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?
>
> I prefer being overly paranoid when it comes to security.
>
> To be fair, I was more immersed in the topic when the change
> happened than I am now. But I am hesitant to make such a
> significant change just before the release. Why wasn't this
> raised in the RFC for this release?
>
> Cheers
> Jan
> --
>

I didn't notice that part of the change until I suggested views on
_users to Jason as a way to ease the transition pain of locking down
what authors may have treated as public profiles. Only then did I see
that it wasn't possible. Arguably, a user's "public profile" is
different app-specific anyway, and should be written to a doc in a
non-system database. I still find the new restriction unnecessary,
though it opens the possibility for admin-only views and that seems
useful enough so I'm +0 on changing anything more now. Fix the numbers
and I'm a go for round 2.

Mime
View raw message