couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: Admin party considered harmful
Date Tue, 19 Apr 2016 07:09:03 GMT
From this thread alone, it should be obvious that this is a contentious topic.

CouchDB 2.0 will have a happy-path setup that requires a setup. You can get
out of it, if you run a single-node instance, but for a cluster, you have to
have an admin user. Discussions about this are about two years old and now
is not the time to revisit them.

This is a good default security that CouchDB has been dinged for over the years
and the devs generally agree that having a server admin at least is a good idea.
Note that this means regular doc r/w is still open to anyone, just db and ddoc
creation is limited to admins.

Then we have to balance this with user-friendliness of course, and I think
things like the setup wizard (thanks Robert!) in Fauxton here can help. This
is what normal users* and especially beginners will go through to set up one
or more 2.0 nodes. As part of the setup procedure, Fauxton could offer a
button “enable CORS for dev purposes“, or something else that helps them set
it up correctly that would replace
that effectively all PouchDB users will just use without learning the
consequences (FWIW, I’ve used this myself, configuring CORS is too hard in

In addition: we have agreed last summer that we are not going to offer the
/_config endpoint in 2.0 because that’d require to build a CP system on top
of an AP one and we didn’t want to delay 2.0 because of that (imagine!) We
made per-node /_config available under /_node/<node-fqdn>/_config and I’d
be happy to have Fauxton use this to make CORS a simple setup. This wouldn’t
work well for larger clusters, but that’s not the target audience here.

* expert users will use deploy scripts and other ways to deploy pre-configured
instances, they will know what they are doing.


> On 19 Apr 2016, at 08:39, Eli Stevens (Gmail) <> wrote:
> Honestly, the entire topic feels over-thought to me. If someone sets
> up a database, has it listen to a port that's open to the internet,
> and doesn't set a password... The situation is pretty much hopeless.
> There's zero chance that *this* is the only security hole that they
> have, and IMO it's kinda silly to think that adding some CouchDB
> nanny-state will result in a now-airtight system. Obviously, sane
> defaults and documentation in the default config are great.
> I've been running into this with some other tools that I use - I want
> to do a certain thing, but the tools prevent me, since the author of
> the tool apparently has a philosophical disagreement with the workflow
> I prefer (to the point of actively inserting somewhat arbitrary
> precondition checks before performing operations that would otherwise
> succeed).
> Needless to say, when I need to do something, and the tool has gone
> out of it's way to block the thing that I'd like to do, it's quite
> frustrating. Please trust me to do my job, and to know my use cases.
> FWIW, all of my CouchDB instances are in admin party, and were an
> attacker to penetrate deep into our systems enough to access CouchDB,
> we'd have been so hopelessly compromised that "oh, they can access the
> DB too" wouldn't meaningfully increase the severity of the event.
> Making me play an obfuscation shell game with a password or auth token
> so that the various programs I have can access the DB isn't going to
> actually make my systems more secure.
> Thanks,
> Eli
> On Mon, Apr 18, 2016 at 6:32 PM, Michael Fair <> wrote:
>> SMTP open relays; wikis; and comment/bulletin board systems have taught us
>> that if there's any hope of monetizing something an ip scanner can attack,
>> they will.
>> This includes a default admin password.  The problem isn't really admin
>> party mode; it's a trivially automated type of default attack profile.
>> I agree with Nolan that people (myself included) succeed in getting
>> started/familiar with Couch largely because of a text editor, admin party
>> mode, curl, and futon.  Following the breadcrumb tutorials and immediately
>> creating/destroying databases; Editing data docs and design docs quickly,
>> directly "on the server"; and practicing replication; without having to
>> first understand the security model/settings to grant oneself permission
>> (or write curl command lines embedding the passwords straight into
>> bash_history).
>> 1)
>> What about only allowing admin party from a machine with the same ip
>> addresses Couch is listening on.  So listen to but make source ip a
>> factor in the privileges assignment.
>> So in a sense, it's multifactor authorization defaulted to only allow
>> certain source ips admin party access (role="admin", connection="source
>> ip/port").
>> 2)
>> Make modes enumerable: "Admin Party", "Production", "Development", "Client"
>> (for clients connecting to server hosts and the default when not supplied),
>> "<User Defined/Added>" (like "Internal Production" which would mean the
>> "Client" request mode isn't allowed)
>> And then by default prevent servers in different modes from
>> replicating/querying each other (add "req_mode" field (the mode of the
>> thing requesting); and "rep_mode" field (the mode the database replying
>> should be in) to the request parameters).
>> Make database operational settings for which request modes are enabled for
>> which reply modes.
>> By default:
>> "Admin Party" only allows requests from "Admin Party" and "Client"
>> "Production" allows "Production" and "Client"
>> "Development" allows "Development" and "Client"
>> 3)
>> Reuse Erlang's magic cookie concept for any access sourced remotely.  If I
>> can, by default, access an admin party database remotely by adding a "magic
>> cookie" (that the server generated) to the URL header in place of a login;
>> and I can only get that cookie by querying the database from the same local
>> machine the server is running, and the server/database must be in admin
>> party mode.  That's A) pretty easy to look up and get the copy/paste
>> instructions to do for a default; B) a clearly placed magic cookie can be
>> retrieved (because it got added to the default server/database json
>> response) by any appropriately authorized user; and C) is not easy for an
>> automated scanner to exploit unless it's already on the same host.
>> A different token would be generated for each server mode; or these magic
>> cookies would be purely an "Admin Party" mode thing.
>> Thoughts?
>> Mike
>> A hosted service would need to have a way to communicate the magic cookies
>> of new databases to their users, or require authentication; but
>> Embedding my server's "Admin Party" <magic cookie> on a client command line
>> On Apr 18, 2016 8:01 AM, "Nolan Lawson" <> wrote:
>>> I do think that there's a tension between the needs of first-timers and
>>> production users. First-timers are already stymied by the lack of CORS by
>>> default, and if we remove the Admin party from the default installation,
>>> it's going to be even more impenetrable for them.
>>> This is why for PouchDB Server we not only made Admin Party the default,
>>> but also completely-open CORS. If I were to go one step further, I might
>>> even make it bind to That has bitten me many many times before on
>>> a fresh install.
>>> Is this something that can be done with Docker? Or maybe by adding presets
>>> to the config UI? (Think Babel presets - e.g. "playground mode" or
>>> "production-ready".)
>>> Cheers,
>>> Nolan
>>> On Sun, Apr 17, 2016 at 12:16 PM, Jan Lehnardt <> wrote:
>>>>> On 17 Apr 2016, at 16:43, Paul Hammant <> wrote:
>>>>> I wasn't being snide, or insulting
>>>> I’m glad to hear that you didn’t mean to be snide.
>>>>> 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.
>>>> I’m not claiming anything, I’m just telling you how this reads to me.
>>>> Best
>>>> Jan
>>>> --
>>>>> - Paul
>>>>> On Sun, Apr 17, 2016 at 8:24 AM, Jan Lehnardt <>
>>>>>>> On 17 Apr 2016, at 05:09, Paul Hammant <>
>>>>>>> (Cultural ref:
>>>>>>> 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
>>> think
>>>> we
>>>>>>> should look for other technologies when there is no cohesive
>>>>>> 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
>>> (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
>>>> newer
>>>>>> version of CouchDB new config variables can appear in default.ini.
>>>> the
>>>>>> install procedure finds an existing local.ini it will not replace
>>> 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
>>> 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
>>>>>> alternative technology, or ask someone nicely to explain this to
>>>>>> 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
>>>> --
>>>> Professional Support for Apache CouchDB:
>>> --
>>> Nolan Lawson

Professional Support for Apache CouchDB:

View raw message