couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: Admin party considered harmful
Date Sun, 17 Apr 2016 12:24:27 GMT

> On 17 Apr 2016, at 05:09, Paul Hammant <paul@hammant.org> wrote:
> 
> (Cultural ref: https://en.wikipedia.org/wiki/Considered_harmful)
> 
> So AdminParty is fun for there 2 minute "hey this stuff is great" tour of
> CouchDB, but it leaves me (and others) worried that we don't know the 52
> specialist knowledge things to do to lock down a couch install completely.
> You know: 443-only, a top-level administrator, sub administrators, regular
> accounts, different read vs write permissions, etc etc. We can't imagine
> going live with a CouchDB solution without that, and it makes us think we
> should look for other technologies when there is no cohesive 100% dev-team
> endorsed page on how to close down the party once and for all. Sooooo - *if
> that page exists, I can't find it*.


> Is the comummunity even in agreement - is it changes to default.ini, local.ini
> (server side), or is it a series of curl statements over the wire (and why)?

No need to be snide about this. A “Why are there two ways to configure
CouchDB?” would have sufficed.

CouchDB has a config system. It is persisted in two .ini files. You can
change settings by editing local.ini and [re]starting CouchDB or without
restarting CouchDB using curl. The latter is rather beneficial in production
systems that don’t want to incur downtimes.

Changes done at runtime are stored in local.ini. When you install a newer
version of CouchDB new config variables can appear in default.ini. If the
install procedure finds an existing local.ini it will not replace it, so
local changes (hence the name) survive software upgrades.

As Bob pointed out, there is a security consideration with ini vs. curl:

If you were to start a CouchDB instance and then add an administrator via
curl, there is an ever so slight chance that someone else gets there before
you. The exact scenario is somewhat convoluted, so I won’t bore you with it.
Suffice it to say, creating an admin in local.ini before the first launch
of CouchDB completely avoids said issue.

* * *

If you don’t feel confident using CouchDB then I suggest you look for
alternative technology, or ask someone nicely to explain this to you,
but pressuring the dev team with an somewhat insulting email is not
appreciated here. Again, a “I find the security system poorly documented,
can someone explain this to me?” would have been much more productive.


Best
Jan
--
Apache CouchDB PMC Chair
http://couchdb.apache.org/conduct.html



Mime
View raw message