On Tue, Feb 14, 2012 at 11:51, Jan Lehnardt <[email protected]> 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 <[email protected]> wrote: >>>> >>>> On Feb 14, 2012, at 19:35 , Randall Leeds wrote: >>>> >>>>> On Tue, Feb 14, 2012 at 10:19, Jan Lehnardt <[email protected]> wrote: >>>>>> >>>>>> On Feb 14, 2012, at 19:13 , Randall Leeds wrote: >>>>>> >>>>>>> On Tue, Feb 14, 2012 at 04:14, Noah Slater <[email protected]> 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.
