Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of b.candler@pobox.com designates
 208.72.237.25 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=date:from:to
	:subject:message-id:references:mime-version:content-type
	:in-reply-to:content-transfer-encoding; q=dns; s=sasl; b=c6KkdfS
	8LH392vQeFLMmSYbiTghwhNLIf0vu5hW+DlBkG7tV+/i5+AyY74eir6pzzM8/Sd6
	VS+RrcYOojMPaEh+9cJZuRR1ACSdUebF6tBwf2vVgs6NW6zUcW7LL0JBHGUyH1dQ
	LFXJ4jk8CIApcTJOIzxLSmgIz1NNqqMLI/tE=
Date: Wed, 3 Feb 2010 21:24:26 +0000
From: Brian Candler <B.Candler@pobox.com>
To: dev@couchdb.apache.org
Subject: Re: DB ACLs (was Re: 0.11 Release / Feature Freeze for 1.0)
Message-ID: <20100203212426.GA10515@uk.tiscali.com>
References: <e282921e1002030921g53af1711r3b46ebe31f4cb38b@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: <e282921e1002030921g53af1711r3b46ebe31f4cb38b@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Content-Transfer-Encoding: quoted-printable

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 mi=
llions
> > of databases on a box if you want to limit it to accessible dbs only.
>=20
> 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 t=
hat
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 b=
e
changed so that non-admin users type in the name of the database they wan=
t
to access.

So far this hasn't answered the question: why not put the authorization i=
n
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 s=
cale to
> > millions of users having access to the same database.
>=20
> 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 use=
rs.
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 applicatio=
n,
   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-lev=
el
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 remov=
e
database1:* roles without having to trouble the systemwide admin.

But that's exactly what my proposal was. In which case, why can we not ju=
st
use this mechanism in the first place?

> > (3) _readers has no concurrency control. One admin making an ACL chan=
ge in
> > futon (say) will silently overwrite changes made around the same time=
 by
> > another admin. This will get worse the more frequently users are adde=
d and
> > removed.
>=20
> _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.=
=20
You could, after all, hardcode

    var security =3D { .... };

in the top of your validate_doc_update; it just avoids you having to touc=
h
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.
>=20
> 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 authori=
zed
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 was=
n't
a fast way to map a uuid back to a database name, but we've already decid=
ed
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 _secu=
rity
> > resources. =A0I think this is quite a severe privacy concern, but it =
is easily
> > fixed.
>=20
> 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.
>=20
> 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 interna=
l
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 addr=
ess
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 sam=
e
database.

And for comparison: if someone signs up for the dev@apache.org mailing li=
st,
they do not get to see the E-mail addresses of all the other members of t=
his
list, and nor should I.

(I think the latter comparison is fair; a couchapp BBS would be a very sw=
eet
thing to have)

> > (9) The _users db itself is world-readable (showing not only who your=
 users
> > are, but their password hashes). Highly undesirable.
>=20
> 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 user=
s.=20
You may be running couchdb on a modest server but your attacker is thousa=
nds
of times more powerful than you, and can spend years doing it if they wan=
t.

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 user=
s
only to see and change their own records), that would be much better IMO.

Regards,

Brian.