You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Paul Hammant <pa...@hammant.org> on 2016/04/17 05:09:59 UTC
Admin party considered harmful
(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)?
- Paul
Re: Admin party considered harmful
Posted by Alexander Shorin <kx...@gmail.com>.
On Tue, Apr 19, 2016 at 10:17 PM, Jan Lehnardt <ja...@apache.org> wrote:
>> On 19 Apr 2016, at 21:06, Alexander Shorin <kx...@gmail.com> wrote:
>>
>> On Tue, Apr 19, 2016 at 5:53 PM, Nolan Lawson <no...@nolanlawson.com> wrote:
>>> Thanks Jan, a setup wizard sounds awesome. Believe me, no one would be
>>> happier than me to deprecate add-cors-to-couchdb! :)
>>
>> What had happened with the story about enable CORS by default, btw?
>
> trouble is with a wildcard Host header, CORS doesn’t allow any
> user credentials (Authorization header etc.) to go over CORS.
>
> So either we need Admin Party (noooo), or the end user has to
> specify the hosts that are allowed to talk to CouchDB, so it’s
> not really CORS-by-default.
Aha, I see. Thanks for explanation!
--
,,,^..^,,,
Re: Admin party considered harmful
Posted by Jan Lehnardt <ja...@apache.org>.
> On 19 Apr 2016, at 21:06, Alexander Shorin <kx...@gmail.com> wrote:
>
> On Tue, Apr 19, 2016 at 5:53 PM, Nolan Lawson <no...@nolanlawson.com> wrote:
>> Thanks Jan, a setup wizard sounds awesome. Believe me, no one would be
>> happier than me to deprecate add-cors-to-couchdb! :)
>
> What had happened with the story about enable CORS by default, btw?
trouble is with a wildcard Host header, CORS doesn’t allow any
user credentials (Authorization header etc.) to go over CORS.
So either we need Admin Party (noooo), or the end user has to
specify the hosts that are allowed to talk to CouchDB, so it’s
not really CORS-by-default.
Best
Jan
--
Re: Admin party considered harmful
Posted by Alexander Shorin <kx...@gmail.com>.
On Tue, Apr 19, 2016 at 5:53 PM, Nolan Lawson <no...@nolanlawson.com> wrote:
> Thanks Jan, a setup wizard sounds awesome. Believe me, no one would be
> happier than me to deprecate add-cors-to-couchdb! :)
What had happened with the story about enable CORS by default, btw?
--
,,,^..^,,,
Re: Admin party considered harmful
Posted by Jan Lehnardt <ja...@apache.org>.
Just to be clear: the wizard exists in master/2.0, all it needs is a “CORS button” :)
Any takers? https://github.com/apache/couchdb-fauxton <https://github.com/apache/couchdb-fauxton>
Best
Jan
--
> On 19 Apr 2016, at 16:53, Nolan Lawson <no...@nolanlawson.com> wrote:
>
> Thanks Jan, a setup wizard sounds awesome. Believe me, no one would be
> happier than me to deprecate add-cors-to-couchdb! :)
>
> - Nolan
>
> On Tue, Apr 19, 2016 at 3:09 AM, Jan Lehnardt <ja...@apache.org> wrote:
>
>> 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
>> https://github.com/pouchdb/add-cors-to-couchdb
>> that effectively all PouchDB users will just use without learning the
>> consequences (FWIW, I’ve used this myself, configuring CORS is too hard in
>> CouchDB).
>>
>> 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.
>>
>> Best
>> Jan
>> --
>>
>>
>>
>>
>>
>>> On 19 Apr 2016, at 08:39, Eli Stevens (Gmail) <wi...@gmail.com>
>> 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 <mi...@daclubhouse.net>
>> 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 0.0.0.0 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" <no...@nolanlawson.com> 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 0.0.0.0. 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 <ja...@apache.org> wrote:
>>>>>
>>>>>>
>>>>>>> On 17 Apr 2016, at 16:43, Paul Hammant <pa...@hammant.org> 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 <ja...@apache.org>
>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>> On 17 Apr 2016, at 05:09, Paul Hammant <pa...@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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Professional Support for Apache CouchDB:
>>>>>> https://neighbourhood.ie/couchdb-support/
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Nolan Lawson
>>>>> nolanlawson.com
>>>>> github.com/nolanlawson
>>>>>
>>
>> --
>> Professional Support for Apache CouchDB:
>> https://neighbourhood.ie/couchdb-support/
>>
>>
>
>
> --
> Nolan Lawson
> nolanlawson.com
> github.com/nolanlawson
--
Professional Support for Apache CouchDB:
https://neighbourhood.ie/couchdb-support/
Re: Admin party considered harmful
Posted by Nolan Lawson <no...@nolanlawson.com>.
Thanks Jan, a setup wizard sounds awesome. Believe me, no one would be
happier than me to deprecate add-cors-to-couchdb! :)
- Nolan
On Tue, Apr 19, 2016 at 3:09 AM, Jan Lehnardt <ja...@apache.org> wrote:
> 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
> https://github.com/pouchdb/add-cors-to-couchdb
> that effectively all PouchDB users will just use without learning the
> consequences (FWIW, I’ve used this myself, configuring CORS is too hard in
> CouchDB).
>
> 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.
>
> Best
> Jan
> --
>
>
>
>
>
> > On 19 Apr 2016, at 08:39, Eli Stevens (Gmail) <wi...@gmail.com>
> 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 <mi...@daclubhouse.net>
> 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 0.0.0.0 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" <no...@nolanlawson.com> 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 0.0.0.0. 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 <ja...@apache.org> wrote:
> >>>
> >>>>
> >>>>> On 17 Apr 2016, at 16:43, Paul Hammant <pa...@hammant.org> 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 <ja...@apache.org>
> wrote:
> >>>>>
> >>>>>>
> >>>>>>> On 17 Apr 2016, at 05:09, Paul Hammant <pa...@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
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>> --
> >>>> Professional Support for Apache CouchDB:
> >>>> https://neighbourhood.ie/couchdb-support/
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Nolan Lawson
> >>> nolanlawson.com
> >>> github.com/nolanlawson
> >>>
>
> --
> Professional Support for Apache CouchDB:
> https://neighbourhood.ie/couchdb-support/
>
>
--
Nolan Lawson
nolanlawson.com
github.com/nolanlawson
Re: Admin party considered harmful
Posted by "Eli Stevens (Gmail)" <wi...@gmail.com>.
On Tue, Apr 19, 2016 at 12:09 AM, Jan Lehnardt <ja...@apache.org> wrote:
> Discussions about this are about two years old and now
> is not the time to revisit them.
I probably didn't do a good job of conveying my stance earlier, but I
wholeheartedly agree with this position.
Thanks,
Eli
Re: Admin party considered harmful
Posted by Jan Lehnardt <ja...@apache.org>.
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 https://github.com/pouchdb/add-cors-to-couchdb
that effectively all PouchDB users will just use without learning the
consequences (FWIW, I’ve used this myself, configuring CORS is too hard in
CouchDB).
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.
Best
Jan
--
> On 19 Apr 2016, at 08:39, Eli Stevens (Gmail) <wi...@gmail.com> 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 <mi...@daclubhouse.net> 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 0.0.0.0 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" <no...@nolanlawson.com> 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 0.0.0.0. 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 <ja...@apache.org> wrote:
>>>
>>>>
>>>>> On 17 Apr 2016, at 16:43, Paul Hammant <pa...@hammant.org> 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 <ja...@apache.org> wrote:
>>>>>
>>>>>>
>>>>>>> On 17 Apr 2016, at 05:09, Paul Hammant <pa...@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
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>> --
>>>> Professional Support for Apache CouchDB:
>>>> https://neighbourhood.ie/couchdb-support/
>>>>
>>>>
>>>
>>>
>>> --
>>> Nolan Lawson
>>> nolanlawson.com
>>> github.com/nolanlawson
>>>
--
Professional Support for Apache CouchDB:
https://neighbourhood.ie/couchdb-support/
Re: Admin party considered harmful
Posted by "Eli Stevens (Gmail)" <wi...@gmail.com>.
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 <mi...@daclubhouse.net> 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 0.0.0.0 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" <no...@nolanlawson.com> 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 0.0.0.0. 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 <ja...@apache.org> wrote:
>>
>> >
>> > > On 17 Apr 2016, at 16:43, Paul Hammant <pa...@hammant.org> 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 <ja...@apache.org> wrote:
>> > >
>> > >>
>> > >>> On 17 Apr 2016, at 05:09, Paul Hammant <pa...@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
>> > >>
>> > >>
>> > >>
>> >
>> > --
>> > Professional Support for Apache CouchDB:
>> > https://neighbourhood.ie/couchdb-support/
>> >
>> >
>>
>>
>> --
>> Nolan Lawson
>> nolanlawson.com
>> github.com/nolanlawson
>>
Re: Admin party considered harmful
Posted by Michael Fair <mi...@daclubhouse.net>.
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 0.0.0.0 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" <no...@nolanlawson.com> 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 0.0.0.0. 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 <ja...@apache.org> wrote:
>
> >
> > > On 17 Apr 2016, at 16:43, Paul Hammant <pa...@hammant.org> 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 <ja...@apache.org> wrote:
> > >
> > >>
> > >>> On 17 Apr 2016, at 05:09, Paul Hammant <pa...@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
> > >>
> > >>
> > >>
> >
> > --
> > Professional Support for Apache CouchDB:
> > https://neighbourhood.ie/couchdb-support/
> >
> >
>
>
> --
> Nolan Lawson
> nolanlawson.com
> github.com/nolanlawson
>
Re: Admin party considered harmful
Posted by Nolan Lawson <no...@nolanlawson.com>.
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 0.0.0.0. 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 <ja...@apache.org> wrote:
>
> > On 17 Apr 2016, at 16:43, Paul Hammant <pa...@hammant.org> 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 <ja...@apache.org> wrote:
> >
> >>
> >>> On 17 Apr 2016, at 05:09, Paul Hammant <pa...@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
> >>
> >>
> >>
>
> --
> Professional Support for Apache CouchDB:
> https://neighbourhood.ie/couchdb-support/
>
>
--
Nolan Lawson
nolanlawson.com
github.com/nolanlawson
Re: Admin party considered harmful
Posted by Jan Lehnardt <ja...@apache.org>.
> On 17 Apr 2016, at 16:43, Paul Hammant <pa...@hammant.org> 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 <ja...@apache.org> wrote:
>
>>
>>> On 17 Apr 2016, at 05:09, Paul Hammant <pa...@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
>>
>>
>>
--
Professional Support for Apache CouchDB:
https://neighbourhood.ie/couchdb-support/
Re: Admin party considered harmful
Posted by Robert Samuel Newson <rn...@apache.org>.
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 <pa...@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 <ja...@apache.org> wrote:
>
>>
>>> On 17 Apr 2016, at 05:09, Paul Hammant <pa...@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
>>
>>
>>
Re: Admin party considered harmful
Posted by Paul Hammant <pa...@hammant.org>.
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 <ja...@apache.org> wrote:
>
> > On 17 Apr 2016, at 05:09, Paul Hammant <pa...@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
>
>
>
Re: Admin party considered harmful
Posted by Jan Lehnardt <ja...@apache.org>.
> On 17 Apr 2016, at 05:09, Paul Hammant <pa...@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
Re: Admin party considered harmful
Posted by Robert Samuel Newson <rn...@apache.org>.
Hi,
"Admin Party" is sometimes interpreted as an endorsement rather than the warning we intend. It means, only, that no administrator has been created yet. Until the first administrator is created, everyone is an administrator, as only administrator can create administrator. You are urged to add an administrator immediately (you can do it before you even start couchdb by editing local.ini).
Changing _security properties of databases is not part of this. The principal securing step is to create at least one administrator.
As Alex notes, we want to make this harder (or impossible) to avoid from 2.0 onward.
B.
> On 17 Apr 2016, at 08:09, Alexander Shorin <kx...@gmail.com> wrote:
>
> Hi Paul!
>
> Yes, Admin Party is harmful and must be fixed if your CouchDB gain
> access not only from localhost. There are no doubts on that.
>
> CouchDB 2.0 will force you to fix it if you're going to setup a cluster.
> --
> ,,,^..^,,,
>
>
> On Sun, Apr 17, 2016 at 6:09 AM, Paul Hammant <pa...@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)?
>>
>> - Paul
Re: Admin party considered harmful
Posted by Alexander Shorin <kx...@gmail.com>.
Hi Paul!
Yes, Admin Party is harmful and must be fixed if your CouchDB gain
access not only from localhost. There are no doubts on that.
CouchDB 2.0 will force you to fix it if you're going to setup a cluster.
--
,,,^..^,,,
On Sun, Apr 17, 2016 at 6:09 AM, Paul Hammant <pa...@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)?
>
> - Paul