On Wed, Feb 10, 2010 at 12:24:26AM +0100, Benoit Chesneau wrote:
> I've read all the thread, and I'm not conviced all readers and admins
> should be in one doc. List could be long also it would require to
> check if one already exists some stuff like it. Why not putting all in
> their docs and making a view on it ?
I'd prefer a real doc or docs too.
But if we have to have an opaque non-scalable non-document object, it would
be better to have one of these things rather than three of them.
> > 3) More system roles.
> >
> > Brian also mentioned something about _user and _anon roles which could
> > be applied to the userCtx automatically. This would be handy in both
> > per-db access control and in validation functions. This will be a bit
> > harder to implement as it touches more of the codebase. I'm also
> > uneasy about these roles as they raise the burden for implementors of
> > pluggable authentication modules.
>
> Everyone could be _anon instead of _admin though.
Maybe _anon isn't even needed, because they will have "name":null.
But you'd want a way of saying "any logged-in user", which could be as
simple as adding a fixed role like "_user" to everyone who has a non-null
name. And if you're going to do that, you might as well add "_anon" role to
everyone who has a null name. Sounds easy to me, but I've not tried coding
it yet.
> > We should also think about making it possible for
> > _admins to interact with the database without the _admin role. They
> > could trigger admin actions with something like sudo.
That's where having a real document would win, because you could use
validate_doc_update for this logic. Such logic already exists in the _users
database, to prevent non-admins from adding roles to themselves.
Personally I think that if a system admin is a role, then a database admin
should be a role, and a database reader should be a role (and by extension,
you could have a system reader role)
Suppose the per-database _security doc or object looked like this:
{
"names":{
"brian":["_admin"], # brian is database-level admin
"jan":["_reader"],
"bob":["_reader","foo"] # foo role has local significance
}
"roles":{
"support":["_reader"] # anyone with support role can read this DB
}
}
You'd merge the roles from the userCtx with these roles to get the effective
set of roles for this user when accessing this particular database.
> Just to be sure everything is one user db ? Just want to make sure
> it's possible to replicate all authentification for a node or even a
> cluster.
That's another reason for doing this in docs. Either make _security a real
doc within each database, which can replicate along with it; or put the
authorizations into the _users database (which is easy with
database-specific roles).
The only objection I've heard to the latter idea is that if a database is
filesystem-copied or renamed, the authorizations won't move with it.
Authorizing against a database uuid rather than database name would solve
that.
Also: given that "bob" on db1 could be a different person than "bob" on db2,
it seems dangerous to replicate or copy the authorizations from one database
to another independently of the users database.
> > 5) drop box
> >
> > If we had the concept of DBs that you could write to but not read
> > from, it would make read-controlled _users dbs compatible with new
> > user signups. This would be not that fun to implement, but potentially
> > useful for lots of other things too.
> >
>
> +1 on this.
Interesting idea - also for logging databases, audit databases etc. Need to
think about the semantics.
Possibly POST to the database itself could have its own role, and it would
ignore _rev so it could only be used to create new docs. But still some
other mechanism would be required for users to change their own passwords.
One idea is to split _reader into two; one role would permit access to
_show, _list and _update whilst blocking all direct access.
Regards,
Brian.
