Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Environment:

      Ubuntu 9.10 64bit

    • Skill Level:
      Committers Level (Medium to Hard)

      Description

      It would be nice if CouchDB had a comprehensive offering for varying levels of access to documents and databases.

      Here are some ideas:

      o User lists are stored in the database, per database.
      o Roles and role membership are stored in the database, per database.
      o ACLs are stored in the database, per database.
      o CouchDB can use ACLs to store and simplify permissions for internal functionality (manage the db, manage users, add roles, add users to roles, etc...)
      o CouchApps can take advantage of the ACLs to support login/logout and arbitrary business rules as needed.
      o A simple API can be made to conduct role, ACL and ownership checks.

      I suppose there is some theory and discussion behind determining whether users, roles or both are stored in ACL rules. Also, something worth discussing is whether the checks are automatically performed by couchdb, or if views are to be performing checks prior to emitting data. Or both...

      Building all this into CouchDB would mean that it has a mechanism for complex applications to be developed. Ones that mandate privacy and other visibility concerns.

        Activity

        Hide
        Alexander Trauzzi added a comment -

        The first part of this note is an aside which could be separated out into another discussion or issue if desired...

        It's important not to conflate the functionality of reading the DB from an application point of view (JSON request coming from a browser) and reading the DB as a function of infrastructure (a scheduled replication).

        I should note that I see the use in allowing replications to happen in the context of a user per database, but not per server. This allows for local copies of DB for higher availability, but they are only populated with data the user can see.
        Ultimately, replications and DBs will have to function in different contexts. Control over what replications a server performs is still a system-wide administrative task to be done with absolute authority.

        Example:
        1. http://www.giantsocialcdcollectionsite.net is running couchdb.
        2. I make a user there.
        3. I start to populate my CD collection and share information with others.\
        4. I'm going on a plane and want my CD collection list with me.
        5. I install CouchDB on my favorite OS via my favorite means.
        6. As I am an administrator on my laptop, I elect to replicate http://www.giantsocialcdcollectionsite.net.
        7. http://www.giantsocialcdcollectionsite.net requires that I authenticate so that it can filter my replication.

        I think you can see how incredibly neat that ends up being...Of course then some people will want ways to obfuscate the _design docs... But that's getting into the nitty gritties.

        Replication should function with indifference towards the DBs, users and CouchApps being replicated and have little to nothing to do with them. It should function behind the scenes as part of a broader, more general systems design.
        That's why things like per-DB roles and users may be nessecary to prevent the server and the databases from bleeding into each other.

        To me, replication is not something my users should even have to know about. You write one app and if you need to scale out, you simply set up replication.

        =

        Anyway...
        This issue that I have made here is over the permissions of authenticated users of the DB and what data they can and cannot read:

        Right now, there is no way to secure a request to http://mycouchdb/mydb/myprivatedata on CouchDB without involving cumbersome workarounds. I am loathe to think of the impact on the project if this is not addressed.

        Show
        Alexander Trauzzi added a comment - The first part of this note is an aside which could be separated out into another discussion or issue if desired... It's important not to conflate the functionality of reading the DB from an application point of view (JSON request coming from a browser) and reading the DB as a function of infrastructure (a scheduled replication). I should note that I see the use in allowing replications to happen in the context of a user per database, but not per server . This allows for local copies of DB for higher availability, but they are only populated with data the user can see. Ultimately, replications and DBs will have to function in different contexts. Control over what replications a server performs is still a system-wide administrative task to be done with absolute authority. Example: 1. http://www.giantsocialcdcollectionsite.net is running couchdb. 2. I make a user there. 3. I start to populate my CD collection and share information with others.\ 4. I'm going on a plane and want my CD collection list with me. 5. I install CouchDB on my favorite OS via my favorite means. 6. As I am an administrator on my laptop, I elect to replicate http://www.giantsocialcdcollectionsite.net . 7. http://www.giantsocialcdcollectionsite.net requires that I authenticate so that it can filter my replication. I think you can see how incredibly neat that ends up being...Of course then some people will want ways to obfuscate the _design docs... But that's getting into the nitty gritties. Replication should function with indifference towards the DBs, users and CouchApps being replicated and have little to nothing to do with them. It should function behind the scenes as part of a broader, more general systems design. That's why things like per-DB roles and users may be nessecary to prevent the server and the databases from bleeding into each other. To me, replication is not something my users should even have to know about. You write one app and if you need to scale out, you simply set up replication. = Anyway... This issue that I have made here is over the permissions of authenticated users of the DB and what data they can and cannot read: Right now, there is no way to secure a request to http://mycouchdb/mydb/myprivatedata on CouchDB without involving cumbersome workarounds. I am loathe to think of the impact on the project if this is not addressed.
        Hide
        Chris Anderson added a comment -

        We already have this, in the sense that replication uses the normal HTTP API. So if a user is not and admin, they will not be able to replicate _design documents to the target.

        Similarly, if the target has a validation function that says all docs must have a foo field, than any docs that are missing a foo field will not be replicated.

        Because CouchDB has not read-authorization model, there isn't the same thing for reads. When we add the ability to control read-access to databases, users will only be able to replicate from databases they can read.

        Show
        Chris Anderson added a comment - We already have this, in the sense that replication uses the normal HTTP API. So if a user is not and admin, they will not be able to replicate _design documents to the target. Similarly, if the target has a validation function that says all docs must have a foo field, than any docs that are missing a foo field will not be replicated. Because CouchDB has not read-authorization model, there isn't the same thing for reads. When we add the ability to control read-access to databases, users will only be able to replicate from databases they can read.
        Hide
        Iain Sproat added a comment -

        I'd like to see authorization based replication - i.e. only being able to replicate parts of the database for which the user is authorized.

        Show
        Iain Sproat added a comment - I'd like to see authorization based replication - i.e. only being able to replicate parts of the database for which the user is authorized.
        Hide
        Chris Anderson added a comment - - edited

        The current update authorization model is very solid, and probably won't be changing.

        There are some good ideas in the ticket regarding read authorization.

        Our big missing piece is per-database reader ACLs. It's not clear if these should be stored in local docs (non-replicating) or normal docs (so they replicate.)

        My guess is that we want them to replicate, as many app installations will span nodes.

        We probably want them in a document that only admins can edit, and I don't think we want the ACLs in _design documents. So maybe we need a new type of document. How does _security/foo sound?

        Currently the db_admins role list is checked against the userCtx roles as well as username. Which means we are dealing with a flat namespace. I've got some notes about the account branch that deal with this stuff that I'll be post soon as well.

        Show
        Chris Anderson added a comment - - edited The current update authorization model is very solid, and probably won't be changing. There are some good ideas in the ticket regarding read authorization. Our big missing piece is per-database reader ACLs. It's not clear if these should be stored in local docs (non-replicating) or normal docs (so they replicate.) My guess is that we want them to replicate, as many app installations will span nodes. We probably want them in a document that only admins can edit, and I don't think we want the ACLs in _design documents. So maybe we need a new type of document. How does _security/foo sound? Currently the db_admins role list is checked against the userCtx roles as well as username. Which means we are dealing with a flat namespace. I've got some notes about the account branch that deal with this stuff that I'll be post soon as well.

          People

          • Assignee:
            Unassigned
            Reporter:
            Alexander Trauzzi
          • Votes:
            4 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:

              Development