couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <kocol...@apache.org>
Subject Re: The replicator needs a superuser mode
Date Wed, 17 Aug 2011 02:34:49 GMT
On Aug 16, 2011, at 10:23 PM, Jason Smith wrote:

> On Wed, Aug 17, 2011 at 7:03 AM, Adam Kocoloski <kocolosk@apache.org> wrote:
>> On Aug 16, 2011, at 5:46 PM, Randall Leeds wrote:
>> 
>>> -1 on _skip_validation and new role
>>> 
>>> One can always write a validation document that considers the role, no? Why
>>> can't users who need this functionality craft a validation function for this
>>> purpose? This sounds like a blog post and not a database feature.
>> 
>> Blech, really?
>> 
>> Q: What request do I issue to guarantee all my documents are stored in this other
database?
>> 
>> A: Unpossible.
>> 
>> Practically speaking we need it at Cloudant because we use replication to move users'
databases between clusters.  If it's not seen as generally useful that's ok, just surprising.
 Best,
> 
> Adam, I'm conflicted. It feels presumptuous to disagree with you and
> the developers, which I've done a lot recently.
> 
> Also, I too struggle with migrating data, verbatim, between servers
> (between couches, and also between Linux boxes).
> 
> But to "guarantee all my documents are stored in this other database"
> is actually incoherent. It is IMHO anti-CouchDB.

Hi Jason, we're going to have to disagree on this one.  Replication is really flexible and
can do lots of things that database replication has not historically been able to do, but
I think it's a sad state of affairs that it's not possible to use replication to create a
replica of an arbitrary database.

> Validation functions, user accounts (which change from couch to
> couch), and security objects (which also change from db to db, and
> couch to couch) all come together to decide whether a change is
> approved (valid). That is very powerful, and very fundamental.
> Providing this "guarantee" betrays the promise that Couch makes to
> developers.

No, it doesn't.  The "guarantee" presumes you have _admin access to the target database. 
Developers shouldn't give that out, just like they shouldn't give out root access to the server
itself.

> People are using validation functions for government compliance, to
> meet regulatory requirements (SOX, HIPAA). IIRC, you are proposing a
> query parameter for Couch to disregard those instructions.

Only if you have _admin access to the database, in which case you can already bypass validation
or do whatever else you want to the data in that database if you're so inclined.

> Validation functions confirm not only authorization, but also
> well-formedness of the documents. So, again, in the real world, where
> many people use _admin accounts, adding a ?force=true parameter sounds
> dangerous.

Well, yes, it would be dangerous to use on every request.

> Do you worry whether, in the wild, people will use it more and more,
> like logging in to your workstation as root/Administrator? It
> eliminates daily annoyances but it is actually very risky behavior.

Meh.  If they choose to bypass their own validation functions that's their concern.  I don't
lose sleep over it.

> Finally, yes, an admin can ultimately circumvent validation functions.
> But to me, that is the checks and balances of real life. If you forget
> your BIOS password, you can physically open the box and move a jumper.
> 
> I do agree about the need to move opaque data around. I disagree that
> a query parameter should allow it. I feel the hosting provider pain.
> The customer creates _design/angry with validate_doc_update:
> 
>    function(newDoc, oldDoc, userCtx, secObj) {
>        throw {forbidden: "I am _design/angry and I hate all documents!"};
>    }
> 
> And now I am responsible for replicating their data, unmolested, all
> over the place.
> 
> -- 
> Iris Couch


Mime
View raw message