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 20:25:47 GMT
On Tue, Feb 14, 2012 at 11:51, Jan Lehnardt <jan@apache.org> wrote:
>
> On Feb 14, 2012, at 20:05 , Jan Lehnardt 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?
>
> This was a lame knee-jerk reply, sorry about that. We should aim to get
> this as right as possible.
>
> The reasoning was as follows:
>
>  - I tried to design the system to be as simple as possible.
>  - I also tried to design it to be the least intrusive to the 1.2.x
>   codebase given the maturity of the branch.
>
> It was these goals and J Chris's email about how to solve the conundrum
> of per-doc-auth* a few weeks earlier (disable views when you enable
> per-doc-auth) that lead to the current situation.
>
> *The security-db system includes per-doc-auth, hence the connection.
>
> In addition, in the design phase, as is the nature of such things, it
> wasn't quite clear how the system would look when done and how we'd
> look at it when it was done (like we do now). So I fully expected then
> (and we see that now) that there's things we could improve and one
> of the things would be to allow user-access to view results for system
> databases.
>
> I'd still say we don't enable this for 1.2.0 as it is close to the
> release, but consider adding an option to enable this (e.g. in the
> _security object) down the road (in 1.2.x and later).
>
>
> Cheers
> Jan
> --

Good summary. Thanks. +1.

Mime
View raw message