couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: Issues blocking the 1.2.0 release
Date Tue, 14 Feb 2012 19:51:18 GMT

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
-- 












Mime
View raw message