couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: DB ACLs (was Re: 0.11 Release / Feature Freeze for 1.0)
Date Thu, 04 Feb 2010 03:21:53 GMT
Hi James,

thanks for your thoughts. I do agree with most points. But I'd like to
propose a pragmatic way out.

I think Chris' auth design is pretty solid. We have been thinking about
this space for over two years now and this is first thing that makes me

Chris' auth design is also not "complete" as in you can have a public
CouchDB running that serves all your security needs. I don't think we
should try and pretend everything is as locked down as it is needed in
every scenario, but get a limited set of scenarios right and expand from
there. I think the current way is a good way forward. We can address
more scenarios further down the line.

If that means some, even many users have to keep combining CouchDB
with a HTTP proxy as they have done in the past, I'm okay with that.

If I thought Chris' design would be fundamentally flawed, I'd have a
different position, though.

We won't ever ship 1.0 if we want CouchDB to be "perfect".


On 3 Feb 2010, at 15:33, James Hayton wrote:

> Hi Everyone-
> I am just an end user of couch right now, but the development of these
> security features are important to me so I thought I would share my
> thoughts.  
> In general and specifically regarding points 5 and 9, I have to agree very
> passionately with Brian.  There is no way that I want my users having access
> to the email addresses, usernames, password hashes, etc... of any other
> users on my system.  That would be a very bad thing and potentially even
> derail some sort of use cases I had thought of for couch in the future.   I
> would also prefer couch to be closed by default and open as needed, but this
> doesn't matter too much as long as I can close it down.  
> I also like the idea of restricting _all_dbs to return only the databases
> that the user has access to.  I would accept it as an admin only resource if
> that’s what everyone thought was best or the only option, but it seems crazy
> to allow users to see the names of databases that they don’t have access to.
> There is no point imho.  They don't have access for a reason.  
> Lastly I would have to say that I would much rather have 0.11 and the
> feature freeze for 1.0 held off for weeks or even months if required to get
> this security stuff worked out properly.  It's incredibly important before
> very many real world applications with sensitive data can actually be built.
> I really believe couch is an amazing piece of software that could create so
> many new opportunities by utilizing it's unique features such as replication
> and hosted applications.  But, the true potential of couch really depends on
> rock solid authorization capabilities.  Without that, I don’t think couch is
> truly ready for a 1.0 release.  Proper authorization probably isn't an easy
> thing to solve and I understand the desire to punt on this stuff and just
> get something working, but I just don't think it’s a good long term
> strategy.  
> I hope I have not come off as unappreciative or demanding.  I truly
> appreciate all the work that you guys are doing regarding security and with
> couch in general.  I also understand that my opinion probably carries very
> little relative weight here since I am not a contributor, but I would really
> plead with everyone not to rush a release or freeze the api without really
> making sure that these issues have been thought through carefully, tested,
> etc...  
> Thanks, 
> James Hayton
> -----Original Message-----
> From: Brian Candler [] 
> Sent: Wednesday, February 03, 2010 1:24 PM
> To:
> Subject: Re: DB ACLs (was Re: 0.11 Release / Feature Freeze for 1.0)
> On Wed, Feb 03, 2010 at 09:21:10AM -0800, Chris Anderson wrote:
>> Let me see if I can address some of these concerns.
> Thank you for taking the time to reply in detail and to implement some of
> the changes.
>>> I believe that in its current form, _all_dbs simply won't scale to
> millions
>>> of databases on a box if you want to limit it to accessible dbs only.
>> This is an interesting one. _all_dbs won't scale indefinitely even
>> before this patch, because it has no built-in pagination abilities.
>> Enhancing this feature to look into each file and keep going to till
>> it finds N that can be listed isn't hard to code. It will be a little
>> more work to make _all_dbs respect startkey and endkey.
> I agree that it's not hard to code. What I mean is that it won't scale if
> the server has to open and read a million files on disk to find the two that
> you have access to.
> Making _all_dbs an admin-only resource as Jan proposed is brutal but
> effective in protecting the server.  (Admins probably do want _all_dbs
> paginated, but that's a separate issue).  Futon would of course have to be
> changed so that non-admin users type in the name of the database they want
> to access.
> So far this hasn't answered the question: why not put the authorization in
> the _users document instead? But I think we're getting to that :-)
>>> (2) _readers is a single monolithic object. I believe that it won't
> scale to
>>> millions of users having access to the same database.
>> It's not meant to support this use case. If you have millions of users
>> with the same access rights, give them a common role and give that
>> role access to the database.
> That doesn't scale either, because what couchdb calls "roles" are really
> what I'd call "groups". That is, they are a system-wide collection of users.
> They are only maintainable by a system-wide administrator.
> What I'm thinking of is that database1 contains application1, with a
> collection of users.  database2 contains application2, with another
> collection of users, and so on.  These databases/applications are hosted on
> the same server, but belong to third parties.
> IMO it's an unrealistic expectation for the database1 owner to come along to
> the system administrator and say:
> 1. I'm having problems with scaling my _readers.
> 2. Please create a new role I can use, and apply this to all my existing
>   readers.
> 3. More importantly, every time I need to add a new user to my application,
>   I will come back to you and ask you to add this role that user.
> Then for the database2 owner to come along and ask for the same.
> That is, because roles are *system-wide* not *database-wide* then the
> management of them doesn't scale if you want to use them for database-level
> access controls.
> Given the above: as system administrator you could decide to create roles
> like "database1:_reader" to simplify administration and avoid role name
> clashes.  You could even arrange the validate_doc_update in the _users
> database so that a delegated person in database1 is able to add and remove
> database1:* roles without having to trouble the systemwide admin.
> But that's exactly what my proposal was. In which case, why can we not just
> use this mechanism in the first place?
>>> (3) _readers has no concurrency control. One admin making an ACL change
> in
>>> futon (say) will silently overwrite changes made around the same time by
>>> another admin. This will get worse the more frequently users are added
> and
>>> removed.
>> _readers / _admins / _security are stored as a raw object without
>> concurrency control, because keeping them as a document adds too much
>> performance overhead on each request. Concurrency control is a
>> tradeoff we make here.
> Sorry to be blunt, but do you have numbers to back that up?  This smells
> very much of premature optimisation.
> In any case: if db:_reader and db:_admin are just roles, you have them in
> the userctx object already.  That's clearly *more* efficient than having
> them separately in the database.
> _security is an edge case. I consider it as an adjunct to the design doc. 
> You could, after all, hardcode
>    var security = { .... };
> in the top of your validate_doc_update; it just avoids you having to touch
> your design doc so often.  Since there's only a single _security document
> it's going to end up cached anyway.
>> The database-specfic roles and names don't belong in the users db. The
>> users db is for answering the question: "who is the user and what
>> roles do they have". The ACLs say which names and roles can read or
>> admin a given database.
>> It's a fact of life that users can rsync db-files around. If the names
>> / roles are in the users db, they get wrong when databases are moved
>> to another host or renamed on the current host.
> The last sentence I agree with. The same is true if you delete a DB and
> recreate one with the same name.
> However, database uuids were proposed recently. If the _users doc authorized
> against uuids rather than database names, would that issue be solved?
> (The ability to have a per-user _all_dbs view would be lost, if there wasn't
> a fast way to map a uuid back to a database name, but we've already decided
> we can live without that)
>> 4 is fixed.
> Thanks. It didn't even add any data privacy, since an _admin could always
> add themselves as a _reader anyway.
>>> (5) Non-admin readers can view the entire _readers, _admins and
> _security
>>> resources.  I think this is quite a severe privacy concern, but it is
> easily
>>> fixed.
>> They can also read the design document. I'm not sure why this is a
>> privacy concern. A user may need to contact a db admin for help with
>> something, it's handy to be able to get a list of them. And it only
>> makes sense that you should be able to see the list of users who can
>> also access the same db you can.
>> If there's consensus that this is indeed an issue, it's not a hard
>> thing to change in the code.
> I await what others say. However I would certainly *not* want the internal
> E-mail addresses of my admins being available to the whole world.  And as an
> end-user of a facebook-style application, I would not want my E-mail address
> known to every other user anywhere on that database.
> For comparison: if you're granted SELECT, INSERT, UPDATE and DELETE
> privileges as an Oracle user, that does not mean you get to find out the
> usernames of the admins, or indeed any other users with rights to the same
> database.
> And for comparison: if someone signs up for the mailing list,
> they do not get to see the E-mail addresses of all the other members of this
> list, and nor should I.
> (I think the latter comparison is fair; a couchapp BBS would be a very sweet
> thing to have)
>>> (9) The _users db itself is world-readable (showing not only who your
> users
>>> are, but their password hashes). Highly undesirable.
>> I actually consider this a feature. We'd like to get some stronger
>> password hashing (see the bcrypt threads) which should help with the
>> password parts.
> At the end of the day, bcrypt is still a hash of a password. Any password
> hash is open to off-line brute-force attack.  You can tune the cost with
> bcrypt, but dictionary attacks are still going to succeed for 90% of users. 
> You may be running couchdb on a modest server but your attacker is thousands
> of times more powerful than you, and can spend years doing it if they want.
> Put it another way: if I suggested that people should start making
> /etc/shadow world-readable, people would laugh.  If I suggested that they
> also post it on their public webserver, I would be laughed out of town.
> Blocking _users is probably good enough for now. I'd be more comfortable if
> _readers didn't fail-open.  I'm also concerned that newcomers may not be
> impressed to find couchdb so "insecure" in its default state.
> However, if _users could be blocked, but there were a restricted API for
> manipulating it (something like _update and _show handlers, allowing users
> only to see and change their own records), that would be much better IMO.
> Regards,
> Brian.

View raw message