Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1278)
Subject: Re: Replication and validate_doc_field
From: Robert Newson <rnewson@apache.org>
In-Reply-To: 
 <CADA=EV8_8O4QVJHg7r+8ayNou0MPj3VT39jHh-apzCgumPJoLw@mail.gmail.com>
Date: Thu, 21 Jun 2012 11:01:34 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <7264DEC7-AA0E-4B72-B99F-8C90D7391AC6@apache.org>
References: 
 <CADA=EV9TtV8QNrfzBbPKgHs6eB1AbwWojHjYzaFz6qUgBW4xHQ@mail.gmail.com>
 <CAHZBNKYu9cPi5a9gitB3Y11u7328GNVizc0RUNx-j_96c0HfkQ@mail.gmail.com>
 <CADA=EV_D5B373-SuR2rBPjzs9XXqia3k7SjS-pHXcUCAP0C8QA@mail.gmail.com>
 <57FA970C-94DA-4804-A07D-B5734ACE5632@apache.org>
 <CADA=EV8_8O4QVJHg7r+8ayNou0MPj3VT39jHh-apzCgumPJoLw@mail.gmail.com>
To: user@couchdb.apache.org


The replicator does not inherently have admin privileges (this would =
make our security model redundant). It has the privileges of the user =
you run it as, and can do only the things that that user can. This is =
why, for example, it's possible that design documents don't get =
replicated, because that requires _admin privilege on the target. Thus, =
there is no mystical interaction, the replicator is just a normal user =
automating the task of ensuring all changes from a source db are copied =
to a target db. To get a 401 means that the value in your "target" field =
did not include authentication details (or included incorrect =
authentication details) and that your target server has =
require_valid_user set to true.

B.


On 21 Jun 2012, at 01:57, Pulkit Singhal wrote:

> Right, so what I'm saying is that the replicator client is being run =
with
> the creds of a super-duper-admin who inherently has _admin privileges.
>=20
> When the same code is run against a DB without any reader roles, =
everything
> works out. But when it is run against a DB with a reader role, it =
fails.
>=20
> I'm hoping that someone will clarify the security constraints around =
how
> replication behaves with db level security in 1.2.0
>=20
> I already read the following tidbit in the wiki:
> http://wiki.apache.org/couchdb/Replication#line-207
> But it has more to do with the replicator DB itself rather than the DB
> being replicated so I'm hoping someone can shed some =
documentation-worthy
> light on how security works around a DB being replicated.
>=20
> On Wed, Jun 20, 2012 at 5:03 PM, Robert Newson <rnewson@apache.org> =
wrote:
>=20
>> The replicator is just a client, so if your validate_doc_update =
doesn't
>> allow it to update, it won't be able to update.
>>=20
>> That said, 401 means you failed to pass a valid user:pass =
combination. You
>> failed to *authenticate*, though the standard description of 401 is
>> notoriously misleading.
>>=20
>> B.
>>=20
>>=20
>> On 20 Jun 2012, at 22:38, Pulkit Singhal wrote:
>>=20
>>> Thanks for pointing out that mis-type, I was indeed referring to
>>> validate_doc_update.
>>> And I'm familiar with the wiki links and the general instructions =
around
>> it
>>> as well.
>>> Perhaps I should explain the motivation behind this question.
>>>=20
>>> When I attempt to replicate from CouchDB 1.2.0 to TouchDB (another
>> flavor),
>>> I receive:
>>> error (
>>>   401,
>>>   "401 unauthorized"
>>> )
>>> A little bit of trial and error showed that as long as I did NOT set
>>> member-roles or member-names on the DB level security in futon ...
>>> everything worked fine.
>>>=20
>>> So now have to wonder why this happens, why would db-member-level
>> security
>>> prevent an _admin from replicating? My 1st guess was that perhaps
>>> validate_doc_update somehow now has a hand in replication as well so =
I
>> just
>>> wanted to check ... if that is not the root cause here then what =
could it
>>> be?
>>>=20
>>> On Wed, Jun 20, 2012 at 3:34 PM, Dave Cottlehuber <dave@muse.net.nz>
>> wrote:
>>>=20
>>>> On 20 June 2012 22:22, Pulkit Singhal <pulkitsinghal@gmail.com> =
wrote:
>>>>> Does validate_doc_field method affect replication authN or authZ =
for
>>>>> CouchDB 1.2.0?
>>>>=20
>>>> Hey Pulkit,
>>>>=20
>>>> I googled authN/Z and found authorisation and authentication. I =
checked
>>>> the source and there's no validate_doc_field.
>>>>=20
>>>> A validate_doc_update function (VDU) is run on a single doc only, =
and
>>>> has access to the proposed new doc as well as the current on-disk
>> version,
>>>> and the user context.
>>>>=20
>>>> So you can tell if the submitter of the update is authenticated or =
not,
>> and
>>>> you can use couchdb roles, or other custom javascript fields in =
your doc
>>>> to decide to reject the docs or not.
>>>>=20
>>>> There's more info on both the wiki and the definitive guide on this =
too.
>>>>=20
>>>> A+
>>>> Dave
>>>>=20
>>=20
>>=20