Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (nike.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
From: Jan Lehnardt <jan@apache.org>
Content-Type: multipart/signed;
 boundary="Apple-Mail=_95299E6C-485A-404E-9172-BD4577FC8EC2";
 protocol="application/pgp-signature"; micalg=pgp-sha512
Message-Id: <28526FBE-4BB3-4437-9F99-98149C946C2B@apache.org>
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1812\))
Subject: Re: Capturing UserCtx automatically
Date: Wed, 19 Feb 2014 14:25:49 +0100
References: 
 <CA+bwPGkn=Q4daAzOXHVu4CzN4JtoQ=Z4CJSbeB0gdVysPkJEKw@mail.gmail.com>
 <3AD8B31E-1BED-41CC-AEF6-D3A873E4CC28@apache.org>
 <CAHdjip+27Cq7AuZGkaE3s-Vf87m_vBhv_PT304=CrncjtWa+NA@mail.gmail.com>
 <F40131FF-0348-4C0D-9C27-4316FBA6C7B6@apache.org>
 <CAHdjipKRueX7NRXqAsA3AEaCqq4VfirdDtxKf-nB8YfKf7XX3g@mail.gmail.com>
 <AE003AA2-6103-42E9-9521-5737DCBE49E4@apache.org>
 <CAHdjip+tc7ieQDbT2oRshuGjy+bNs_XU6sQybWdYDgXJKRfaEQ@mail.gmail.com>
 <E77A610F-8452-473C-8DBC-1473F00D4FD3@apache.org>
 <CAHdjipJa4SobKXL6XLA5LG6X1ijCcaqxiL9OuFWC5bmCS+3a5w@mail.gmail.com>
To: "dev@couchdb.apache.org Developers" <dev@couchdb.apache.org>
In-Reply-To: 
 <CAHdjipJa4SobKXL6XLA5LG6X1ijCcaqxiL9OuFWC5bmCS+3a5w@mail.gmail.com>

--Apple-Mail=_95299E6C-485A-404E-9172-BD4577FC8EC2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On 19 Feb 2014, at 14:19 , Alexander Shorin <kxepal@gmail.com> wrote:

> On Wed, Feb 19, 2014 at 5:15 PM, Jan Lehnardt <jan@apache.org> wrote:
>> On 19 Feb 2014, at 13:27 , Alexander Shorin <kxepal@gmail.com> wrote:
>>=20
>>> On Wed, Feb 19, 2014 at 4:17 PM, Jan Lehnardt <jan@apache.org> =
wrote:
>>>> On 19 Feb 2014, at 13:02 , Alexander Shorin <kxepal@gmail.com> =
wrote:
>>>>=20
>>>>> On Wed, Feb 19, 2014 at 3:59 PM, Jan Lehnardt <jan@apache.org> =
wrote:
>>>>>> On 19 Feb 2014, at 11:42 , Alexander Shorin <kxepal@gmail.com> =
wrote:
>>>>>>=20
>>>>>>> On Wed, Feb 19, 2014 at 2:24 PM, Robert Samuel Newson
>>>>>>> <rnewson@apache.org> wrote:
>>>>>>>> validate_doc_update(oldDoc, newDoc, userCtx) {
>>>>>>>>=20
>>>>>>>> if (newDoc.audit_trail[0].user !=3D userCtx.name) {
>>>>>>>> throw({forbidden: "You didn=92t add your name to the audit =
trail!"});
>>>>>>>> }
>>>>>>>> =85
>>>>>>>> }
>>>>>>>=20
>>>>>>> There is one issue with such approach: replications. You will =
not be
>>>>>>> able to replicate documents which has different username in
>>>>>>> audit_trail from those one who runs the replication. Or, to be =
more
>>>>>>> detailed, you'll replicate fine all documents till the design =
document
>>>>>>> which brings this validation function to your database and after =
that
>>>>>>> you'll only able to store documents which matches replication's =
user.
>>>>>>=20
>>>>>> You could add the replication user to the validation function and =
keep
>>>>>> the original author.
>>>>>=20
>>>>> Sure, I could. But this would be tricky and unclear for other =
users
>>>>> that just wanted to grab the data from CouchDB.
>>>>=20
>>>> how so?
>>>=20
>>> Let's say we have some database where multiple users are =
collaborating
>>> upon some stuff. Let it be image hosting service based on CouchDB
>>> where friends shares images between. Your users allowed to post new
>>> docs with images, but they don't wanted to see how others users
>>> changes docs that they owned. We forbidden such actions via
>>> validate_doc_update function by checking if doc.author matches
>>> userCtx.name. So, that's the case: you allowed to update own =
documents
>>> and only allow to read the others.
>>>=20
>>> Now some user wanted to replicate this database to local CouchDB. He
>>> already has his own personal credentials. And he'll use them in
>>> replication and I wonder if he's able to recall another account to =
use
>>> for replications. Also, if I create special username which is able =
to
>>> bypass validation function ... well, that's a bug in the system -
>>> what's the reason left to use restricted accounts when you have =
access
>>> to more powerful ones?
>>=20
>> In this scenario, the other user would not be able to invoke a =
replication
>> with the replication-user credentials.
>=20
> Which bypassed validation rules, right? And what stops him to use the
> same credentials to push data back from local instance to public one?
> If it workarounds validation rules, he'll be able to rewrite docs that
> he shouldn't be able to. That's the problem.

No, I mean in my scenario the person who could make a local change to a =
doc
they didn=92t create would *NOT* have the replicator user=92s =
credentials, so
they could NOT replicate things back elsewhere.

You point is important though: you need to set these things up carefully =
:)

Best
Jan
--=20


--Apple-Mail=_95299E6C-485A-404E-9172-BD4577FC8EC2
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJTBLDdAAoJENnuAeR4Uq7kK4QQAJvKovw0xGXsXhJRxSzmJ0Ih
v9PouChWWKRshQQoC1KIMb9Q5u15uMweBJ5EsIfM8qWdTvqrX9ujiyZ1y/reCkoF
ULBYV16IJsQ0hkqyBYZm6KhDlcn5O/sfv1RwQcb55XxDAzlfctyoDiYN2bdUv3HN
3LS6F6UbimrImeoJY2mw6srS5NCSAVOJXZs8iJt60LpgjtWODBzQfRlefSop7NKq
b8xcjQyHSutfTyVMmdKzv5pGyDyKgzHSfantD/LPGTVsi1o+j7E0vLhT8d9KL1mo
PAFJUUed3+7uOTjGfUmp+ui62V5BnxKSwGQ9eYfJHP4v20TAKn6wHNuoT4sbGMfT
FpDq4E9KHyti33LT6vY98LkjaLnduF3HyK+egGYCwnU17hM6vY6FSk2U3xa9H92Z
ylCAygiuGRC+PoZsiIMJPvFqm9ySqLbD3gJLWe3d/IxedDR6W3BqAkyARtV2h6tO
EMz+3l3ZmMlqNRHbIe2djZOKrEBC81eEUETJzeRsrb0P9eD84tRWwyOsFdOe3gnh
gju6Ec6h3P+d68mQiWlioRiW3uAFkvGbBP0WImfP4HzZI+JHzDjzmVRp8xelJ91l
3JguzZLg457+/OmayyX2ompy1AUGaHF6Wev4MLJOD19+RnXZxgZFxd2F3/Dnf3kf
eQCQwAauiN1Jiov+RxMT
=M6PM
-----END PGP SIGNATURE-----

--Apple-Mail=_95299E6C-485A-404E-9172-BD4577FC8EC2--