couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jean-Pierre Fiset (JIRA)" <>
Subject [jira] [Commented] (COUCHDB-1475) _users design documents access
Date Fri, 12 Apr 2013 17:08:16 GMT


Jean-Pierre Fiset commented on COUCHDB-1475:

I agree that this needs to be revisited. I wish that the _users database was consistent with
other databases. Currently, I want some roles to be able to manage other users, which requires
access to some views. Yet, I do not wish to give those roles the ability to change the design

It seems that the "members" section of the security document is useless in the case of the
_users database.
> _users design documents access
> ------------------------------
>                 Key: COUCHDB-1475
>                 URL:
>             Project: CouchDB
>          Issue Type: Question
>          Components: Database Core
>    Affects Versions: 1.2
>         Environment: Debian/testing
>            Reporter: St├ęphane Alnet
>            Priority: Minor
> Sorry I'm coming in late on this topic, I found this while testing my existing code against
> The comments for commit e5503ffef957dc5e8784c7223e318738ae79b6df indicate for `after_doc_read`:
>           If the doc is a design doc and the userCtx doesn't identify
>           an admin or db-admin:
>           -> 403 // Forbidden
> This breaks the (previously working) case where access to the _users database is restricted
using a "members" security property, and authorized users could use a couchapp found in the
_users database to manager user records.
> (These power-users would have, say, "user_manager_ro" and "user_manager_rw" roles assigned
to them, with the ro/rw aspect handled by a specific validate_doc_udpate() which would be
part of the couchapp; the roles were entered in the _users' database members.roles security
> Pointing me back to a discussion explaining the background for this new behavior would
be sufficient, if it is effectively a desirable side-effect and things will remain as they
are. Otherwise it seems a finer-grained logic for after_doc_read() would be able to restore
the desired result, along the lines of:
>           If the doc is a design doc and (there are no security members.roles and no
members.names) and (the userCtx doesn't identify
>           an admin or db-admin)
>           -> 403 // Forbidden
> Thanks,
> S.
> PS: Overall I'm surprised the changes in that commit used new Erlang code rather than
suggesting best-practices using the exisiting security features. I don't understand how hiding
the design documents enhances security ("security by obscurity"), but that's beyond what I'm
asking here.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message