couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Cottlehuber <>
Subject Re: use case: replication of many databases, with/by many users
Date Mon, 24 Sep 2012 18:18:12 GMT
On 24 September 2012 06:00, svilen <> wrote:
> i've been reading
> for a while, but some things inbetween them are missing.
> so after some trial-and-errors here's what i understand/assume so far:
> * couchdb users are per server-instance, in separate /_users db
> * an user can see/change only his /_users/id doc-profile (this
>   also means s/he can add hirself to any known/guessed role. hence
>   roles are not for guarding unauthorized use - but only for
>   specialization)

Yes, note you can use validation functions to enforce pretty much any
constraints you like, including deciding who can update roles.

> * databases can have /db/_security.readers.names as list of
> users allowed to read+write (or .admins for extra stuff)
> ** replication as plain http+read/write is under these permissions too
> - so cant replicate databases if unauthorized in them
> * only server-admins can create/delete a db
> * only db-or-server-admins can change db/_security
> * /db/_security is NOT replicated

I believe so, but I'm not sure how this security object is stored in
the .couch file.

> * /_users can be replicated manually

Yes. Again its just a normal DB so has the same replication
constraints you've noted.

> are these correct? especially the the /db/_security being
> non-replicable ? i could not make it replicate. If that is the case,
> then making *equal* copy of some database is not that
> straightforward - one has to manualy query+copy the _security object.
> repeat for each if there are many-many databases.

I think that's correct.

> so, if the couchdb user-authentication is to be used @ server, any
> create-db or add/del-user-to-db has to be made explicitly by some
> server-side app, before being usable. Or, if made locally, e.g. because
> no connection, (assuming u can do anything locally), they once there
> is connection, and the local db/changes is published to server, these
> have to be all re-played at server-side to actualy happen - i.e. create
> db, replicate data, then re-play add/del-user @ server to rebuild the
> db/_security.
> or am i missing something?
> ciao
> svilen

Yes. This is a fundamental constraint in _any_ distributed system -
for security there is only one instance you can trust - yourself. In
the infamous words of Lenin: "Trust is good, but control is better.".

In sharded systems the boundary of trust would need to be extended to
the cluster.


View raw message