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 <j...@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) <wickedg...@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 <mich...@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 <j...@apache.org> wrote: >>>>> >>>>>> >>>>>>> On 17 Apr 2016, at 16:43, Paul Hammant <p...@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 <j...@apache.org> >> wrote: >>>>>>> >>>>>>>> >>>>>>>>> On 17 Apr 2016, at 05:09, Paul Hammant <p...@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/
