couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Samuel Newson <rnew...@apache.org>
Subject Re: Admin party considered harmful
Date Sun, 17 Apr 2016 15:12:54 GMT

fwiw I didn't read you as snide or insulting, just perplexed by couchdb's default security
settings, and I can't fault anyone for that.

From 2.0 onward we'd like to force the setting of an admin user/pass before we'll listen to
any port, I'm not sure who is working on it, so it might slip to a point release.

B.

> On 17 Apr 2016, at 15:43, Paul Hammant <paul@hammant.org> wrote:
> 
> I wasn't being snide, or insulting - that's just your perception.  If I
> wanted to write "I find the security system poorly documented,
> can someone explain this to me" (your suggestion), I would have written it
> as "I find the documentation of the security could be expanded for newbies, can
> someone explain this to me" and avoid a reference to "poorly".
> 
> I'm an Apache member - 'hammant' - and wouldn't do what you're claiming I'm
> doing.
> 
> - Paul
> 
> On Sun, Apr 17, 2016 at 8:24 AM, Jan Lehnardt <jan@apache.org> wrote:
> 
>> 
>>> 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