You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by "Jason Smith (JIRA)" <ji...@apache.org> on 2010/07/26 11:39:59 UTC
[jira] Created: (COUCHDB-835) Whitelisting which config variables
may be changed via HTTP
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.
[jira] Updated: (COUCHDB-835) Whitelisting which config variables
may be changed via HTTP
Posted by "Jason Smith (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jason Smith updated COUCHDB-835:
--------------------------------
Attachment: 0004-Document-the-whitelist-process.patch
Patch 4: Description and examples in the local.ini
> 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
> Attachments: 0001-Refactor-read-only-config-handlers-to-be-near-each-o.patch, 0002-Refactor-PUT-and-DELETE-config-handlers-to-a-wrapper.patch, 0003-Support-a-whitelist-for-modifying-the-config-via-HTT.patch, 0004-Document-the-whitelist-process.patch
>
>
> 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.
[jira] Updated: (COUCHDB-835) Whitelisting which config variables
may be changed via HTTP
Posted by "Jason Smith (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jason Smith updated COUCHDB-835:
--------------------------------
Attachment: 0001-Refactor-read-only-config-handlers-to-be-near-each-o.patch
Patch 1: No-op refactor just to make subsequent patches easier to reason about. This patch makes the code cleaner at any rate.
> 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
> Attachments: 0001-Refactor-read-only-config-handlers-to-be-near-each-o.patch
>
>
> 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.
[jira] Updated: (COUCHDB-835) Whitelisting which config variables
may be changed via HTTP
Posted by "Jason Smith (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jason Smith updated COUCHDB-835:
--------------------------------
Attachment: (was: 0001-Refactor-read-only-config-handlers-to-be-near-each-o.patch)
> 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
> Attachments: 0001-Refactor-read-only-config-handlers-to-be-near-each-o.patch
>
>
> 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.
[jira] Updated: (COUCHDB-835) Whitelisting which config variables
may be changed via HTTP
Posted by "Jason Smith (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jason Smith updated COUCHDB-835:
--------------------------------
Attachment: 0002-Refactor-PUT-and-DELETE-config-handlers-to-a-wrapper.patch
Patch 2: No-op wrapper around PUT and DELETE config handlers. This creates a choke point for later policy enforcement.
> 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
> Attachments: 0001-Refactor-read-only-config-handlers-to-be-near-each-o.patch, 0002-Refactor-PUT-and-DELETE-config-handlers-to-a-wrapper.patch, 0003-Support-a-whitelist-for-modifying-the-config-via-HTT.patch, 0004-Document-the-whitelist-process.patch
>
>
> 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.
[jira] Updated: (COUCHDB-835) Whitelisting which config variables
may be changed via HTTP
Posted by "Jason Smith (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jason Smith updated COUCHDB-835:
--------------------------------
Attachment: 0003-Support-a-whitelist-for-modifying-the-config-via-HTT.patch
Patch 3: Whitelist sample implementation and unit tests
> 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
> Attachments: 0001-Refactor-read-only-config-handlers-to-be-near-each-o.patch, 0002-Refactor-PUT-and-DELETE-config-handlers-to-a-wrapper.patch, 0003-Support-a-whitelist-for-modifying-the-config-via-HTT.patch, 0004-Document-the-whitelist-process.patch
>
>
> 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.
[jira] Updated: (COUCHDB-835) Whitelisting which config variables
may be changed via HTTP
Posted by "Jason Smith (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jason Smith updated COUCHDB-835:
--------------------------------
Comment: was deleted
(was: No-op refactor just to make subsequent patches easier to reason about. This patch makes the code cleaner at any rate.)
> 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
> Attachments: 0001-Refactor-read-only-config-handlers-to-be-near-each-o.patch
>
>
> 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.
[jira] Closed: (COUCHDB-835) Whitelisting which config variables
may be changed via HTTP
Posted by "Jan Lehnardt (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jan Lehnardt closed COUCHDB-835.
--------------------------------
Fix Version/s: 1.1
Resolution: Fixed
> 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
> Fix For: 1.1
>
> Attachments: 0001-Refactor-read-only-config-handlers-to-be-near-each-o.patch, 0002-Refactor-PUT-and-DELETE-config-handlers-to-a-wrapper.patch, 0003-Support-a-whitelist-for-modifying-the-config-via-HTT.patch, 0004-Document-the-whitelist-process.patch
>
>
> 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.
[jira] Updated: (COUCHDB-835) Whitelisting which config variables
may be changed via HTTP
Posted by "Jason Smith (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jason Smith updated COUCHDB-835:
--------------------------------
Attachment: 0001-Refactor-read-only-config-handlers-to-be-near-each-o.patch
No-op refactor just to make subsequent patches easier to reason about. This patch makes the code cleaner at any rate.
> 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
> Attachments: 0001-Refactor-read-only-config-handlers-to-be-near-each-o.patch
>
>
> 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.