Prevent modification of /_users/_security object with opt-out ini file setting

[wohali]

Expected Behavior

Modifying the _security object inside of _users is unsupported, and can lead to some unusual behaviour - see #1556.

Current Behavior

We allow people to shoot themselves in the foot by modifying _users/_security.

Possible Solution

Always return a 403 on write attempts for _users/_security. @rnewson do you have any comment on this?

Steps to Reproduce (for bugs)

1. dev/run -n 1 --with-admin-party-please
2. `curl -X PUT http:https://localhost:15984/_users/_security -d '{"foo": "bar"}'

Context

People are trying to change the rules for who can read/write documents in _users and it goes very badly.

Your Environment

• Version used: 2.2.0

[rnewson]

It's a difficult thing to remove at this late stage, though I agree with the proposal.

Should we fold this into the broader push to hide these databases behind an API that enforces only the semantics we wish?

[wohali]

@rnewson If a naive block is a problem for 2.x, we can just say this is backwards-incompatible and fold it into #1504 if you want, sure. I just thought maybe a 2.3 that blocked _users/_security writes wouldn't be too hard to implement, and shouldn't affect TOO many people...

[rnewson]

It's hard to know how many have changed the security object of _users. Those that have done so and not encountered a problem will be broken by this change; those that have encountered a problem will have had to reverse their change already.

I think we should save the breakingchangeness until we present a full replacement for this; the API that sits in front of this database and only permits what it ought to.

[wohali]

+1, let's leave this unti #1504. I'll close this for now.

[janl]

Alternatively, like we've done with default db security and making _all_dbs an opt-in config value could help folks until we have a proper fix.

[rnewson]

yes, I can see that. [couchdb] users_db_security_editable=false|true or something, defaulting to false in the new default.ini

[wohali]

If we're OK with that alternative for 2.x, I'll re-open this.