On 24 September 2012 06:00, svilen <[email protected]> wrote: > i've been reading > http://wiki.apache.org/couchdb/Security_Features_Overview > http://wiki.apache.org/couchdb/Replication > 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. A+ Dave
