couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Pierre Fiset ...@fiset.ca>
Subject Re: The replicator needs a superuser mode
Date Wed, 17 Aug 2011 15:46:51 GMT
I think that the operations of replication and backing up are quite different. Although some
are
using the replication features for backing up, I tend to think of replication as an operation
taking place between two nodes that do not necessarily trust one another.

If what you are proposing is a special privilege given to the admin party, then I do not have
much of an issue with this, since administrators already have intimate access to the server.
However, the concept of creating a new "replicator" role, which would supersede the validation
functions is another thing.

In applications that must ensure that some document types have a given structure, opening
the
door to a user (and here I assume a user that attempts a replication from a different node,
not
a local administrator performing a back up) to work around the validation function is probably
a
bad idea. If the validation function could not be counted on, it would really affect the way
an
application must be written.

JP

On 11-08-16 02:40 PM, Adam Kocoloski wrote:
> Hi Jean-Pierre, I'm not quite sure I follow that line of reasoning.  A user with _admin
privileges on the database can easily remove any validation functions prior to writing today.
 In my proposal skipping validation would require _admin rights and an explicit opt-in on
a per-request basis.  What are you trying to guard against with those validation functions?
 Best,
> 
> Adam
> 
> On Aug 16, 2011, at 2:29 PM, Jean-Pierre Fiset wrote:
> 
>> I understand the issue brought by Adam since in our CouchDb application, there is
a need to have a replicator role and the validation functions skip most of the tests if the
role is set for the current user.
>>
>> On the other hand, at the current time, I am not in favour of making super users
for the sake of replication. Although it might solve the particular problem stated, it removes
the ability for a design document to enforce some "invariant" properties of a database.
>>
>> Since there is already a way to allow a "replicator" to perform any changes (role
+ proper validation function), I do not see the need for this change. Since the super replicator
user removes the ability that a database has to protect the consistency of its data, and that
there does not seem to be a work-around, I would rather not see this change pushed to CouchDb.
>>
>> JP
>>
>> On 11-08-16 10:26 AM, Adam Kocoloski wrote:
>>> One of the principal uses of the replicator is to "make this database look like
that one".  We're unable to do that in the general case today because of the combination of
validation functions and out-of-order document transfers.  It's entirely possible for a document
to be saved in the source DB prior to the installation of a ddoc containing a validation function
that would have rejected the document, for the replicator to install the ddoc in the target
DB before replicating the other document, and for the other document to then be rejected by
the target DB.
>>>
>>> I propose we add a role which allows a user to bypass validation, or else extend
that privilege to the _admin role.  We should still validate updates by default and add a
way (a new qs param, for instance) to indicate that validation should be skipped for a particular
update.  Thoughts?
>>>
>>> Adam
>>
> 


Mime
View raw message