Whitelisting which config variables may be changed via HTTP
-----------------------------------------------------------
Key: COUCHDB-835
URL: https://issues.apache.org/jira/browse/COUCHDB-835
Project: CouchDB
Issue Type: New Feature
Components: HTTP Interface
Affects Versions: 1.0
Environment: Linux, Erlang R13B03
Reporter: Jason Smith
Priority: Minor
A database rite of passage is partitioning responsibility into system
administrators and DBAs. CouchDB has reached this point. Congratulations!
The _config API allows changing the .ini file completely over authenticated
HTTP, without requiring the CouchDB admin to log in to the server OS.
Unfortunately, some configuration settings are OS-oriented (http.port,
couchdb.view_index_dir); others are strictly database settings
(uuids.algorithm); and still others must be decided case-by-case (log.level,
couchdb.max_document_size).
In short, CouchDB should support a whitelist, with which the system
administrator can specify which _config values are may be modified by the DBA,
and which are read-only.
I propose that this whitelist is itself a config option,
httpd.config_whitelist. If it is undefined, there is no whitelist and no change
of behavior. If specified, the whitelist is an Erlang list of 2-tuples of the
format:
[{section1, key1}, {section2, key2}, {section_with_wildcard, "*"}, ...]
When processing a PUT or DELETE, CouchDB confirms inclusion of the section/key
in the whitelist.
I foresee two modes of operation:
* DBA is top dog: The whitelist includes {httpd,config_whitelist} itself. Thus
the DBA may modified the list later over HTTP. The whitelist is just a
safeguard against accidental changes.
* Sysadmin is top dog: The whitelist does not include {httpd,config_whitelist}.
The DBA is unable to change the list and may only ask politely for updates to
the policy.
(In any case, you can always edit the .ini file and _restart from the server
OS.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
