On Tue, Feb 14, 2012 at 11:05, Jan Lehnardt <[email protected]> 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? > > 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.
