On Tue, Feb 16, 2010 at 12:08 PM, Brian Candler wrote:
> On Tue, Feb 16, 2010 at 09:56:57AM -0800, Chris Anderson wrote:
>> This is just an artifact of following trunk. Because _admins used to
>> store a mixed list of names and roles, users upgrading from 0.10.x
>> will lose any defined db-admins.
On Tue, Feb 16, 2010 at 09:56:57AM -0800, Chris Anderson wrote:
> This is just an artifact of following trunk. Because _admins used to
> store a mixed list of names and roles, users upgrading from 0.10.x
> will lose any defined db-admins. I think this is the most secure
> choice.
Just to be clear,
On Tue, Feb 16, 2010 at 3:12 AM, Brian Candler wrote:
> And a bit more debugging:
>
> diff --git a/src/couchdb/couch_db.erl b/src/couchdb/couch_db.erl
> index 6d5da15..c2826e3 100644
> --- a/src/couchdb/couch_db.erl
> +++ b/src/couchdb/couch_db.erl
> @@ -238,7 +238,9 @@
> check_is_admin(#db{user_
And a bit more debugging:
diff --git a/src/couchdb/couch_db.erl b/src/couchdb/couch_db.erl
index 6d5da15..c2826e3 100644
--- a/src/couchdb/couch_db.erl
+++ b/src/couchdb/couch_db.erl
@@ -238,7 +238,9 @@
check_is_admin(#db{user_ctx=#user_ctx{name=Name,roles=Roles}}=Db) ->
AdminRoles -> % same
On Tue, Feb 09, 2010 at 07:30:37PM +, Brian Candler wrote:
> > couch_db:check_is_admin() should allow access in this case.
> >
> > If you can reliably reproduce this, I'd like to fix it.
>
> Yes, I can reliably reproduce.
I have just upgraded to latest trunk and for some reason I can't repro
On Tue, Feb 09, 2010 at 09:04:49AM -0800, Chris Anderson wrote:
> If you do a get against /_session does it show you as an admin?
Yes (see below)
> couch_db:check_is_admin() should allow access in this case.
>
> If you can reliably reproduce this, I'd like to fix it.
Yes, I can reliably reprodu
On Tue, Feb 9, 2010 at 2:04 AM, Brian Candler wrote:
> On Tue, Feb 09, 2010 at 10:00:53AM +, Brian Candler wrote:
>> Even going back to Admin Party it doesn't work:
>>
>> $ curl -X POST -d '{"map":"function(doc) {}"}'
>> http://127.0.0.1:5984/briantest/_temp_view
>> {"error":"unauthorized","r
On Tue, Feb 09, 2010 at 10:00:53AM +, Brian Candler wrote:
> Even going back to Admin Party it doesn't work:
>
> $ curl -X POST -d '{"map":"function(doc) {}"}'
> http://127.0.0.1:5984/briantest/_temp_view
> {"error":"unauthorized","reason":"You are not authorized to access this db."}
>
> How
Unless I'm doing something daft, it seems that readeracl is blocking me from
accessing _temp_view, even as a database admin or a system admin.
$ curl http://brianadmin:brianad...@127.0.0.1:5984/briantest/_admins
{"names":["brianadmin"],"roles":[]}
$ curl http://brianadmin:brianad...@127.0.0.1:598
ad about that.
James Hayton
-Original Message-
From: Jan Lehnardt [mailto:j...@apache.org]
Sent: Saturday, February 06, 2010 11:38 AM
To: dev@couchdb.apache.org
Subject: Re: DB ACLs (was Re: 0.11 Release / Feature Freeze for 1.0)
On 6 Feb 2010, at 10:52, Chris Anderson wrote:
> On Sat, Feb
On Mon, Feb 8, 2010 at 8:19 AM, Brian Candler wrote:
> Sorry to drag on about this, but I have another problem with the readeracl
> branch.
>
> As far as I can tell, it's impossible to test in validate_doc_update whether
> the user is listed in the database-level _admins resource.
This is a good
Sorry to drag on about this, but I have another problem with the readeracl
branch.
As far as I can tell, it's impossible to test in validate_doc_update whether
the user is listed in the database-level _admins resource. Example:
$ curl http://brianadmin:brianad...@127.0.0.1:5984/briantest/_admins
On Sat, Feb 06, 2010 at 10:52:57AM -0800, Chris Anderson wrote:
> I'd be pretty surprised if the ACLs that ship with 0.11 are
> significantly different from what I committed last week.
I thought so, which is why I haven't coded up any alternative in erlang.
> Can you explain your application need
On 6 Feb 2010, at 10:52, Chris Anderson wrote:
> On Sat, Feb 6, 2010 at 1:58 AM, Brian Candler wrote:
>> A thought.
>>
>> The current security model requires you spread information in three places:
>> _readers (has access to database); _security (for controlling updates);
>> _admins (can update
On Sat, Feb 6, 2010 at 1:58 AM, Brian Candler wrote:
> A thought.
>
> The current security model requires you spread information in three places:
> _readers (has access to database); _security (for controlling updates);
> _admins (can update security and ddocs)
>
> What if this was replaced by a s
A thought.
The current security model requires you spread information in three places:
_readers (has access to database); _security (for controlling updates);
_admins (can update security and ddocs)
What if this was replaced by a single resource, _security, structured like
this?
{
"names
I think it's time to declare my interest.
The CouchDB-backed application I've been working on is now available here:
http://www.deploy2.net/
It's basically an IP address database / network asset inventory. CouchDB has
been a great match for this, especially some funky map-reduce logic for
indexin
On Wed, Feb 03, 2010 at 02:27:56PM -0800, Jan Lehnardt wrote:
> > Sorry to be blunt, but do you have numbers to back that up? This smells
> > very much of premature optimisation.
>
> Reading a document costs:
>
> 1 disk seek to the end of the db file to grab the b-tree root
> + n disk seek
ht through carefully, tested,
> etc...
>
> Thanks,
>
> James Hayton
>
>
>
>
>
> -Original Message-
> From: Brian Candler [mailto:b.cand...@pobox.com]
> Sent: Wednesday, February 03, 2010 1:24 PM
> To: dev@couchdb.apache.org
> Subject: Re
On Wed, Feb 3, 2010 at 1:35 PM, Brian Candler wrote:
> On Wed, Feb 03, 2010 at 09:24:26PM +, Brian Candler wrote:
>> > > (9) The _users db itself is world-readable (showing not only who your
>> > > users
>> > > are, but their password hashes). Highly undesirable.
>> >
>> > I actually consider
Original Message-
From: Brian Candler [mailto:b.cand...@pobox.com]
Sent: Wednesday, February 03, 2010 1:24 PM
To: dev@couchdb.apache.org
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 c
On 3 Feb 2010, at 13:24, Brian Candler wrote:
>> _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
One last thing on _reader behaviour.
If you try to access a database as a non-admin user, but don't have _reader
rights, I think you should get a 404 back which is indistinguisable from
"database does not exist". Otherwise, you have an obvious way to probe for
database names, and if databases are
On Wed, Feb 03, 2010 at 09:24:26PM +, Brian Candler wrote:
> > > (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
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 datab
On 3 Feb 2010, at 09:21, Chris Anderson wrote:
>> I do see logic in keeping the admin/reader authorizations for a database
>> within the database itself. The problems are:
>>
>> (1) _all_dbs currently shows everything - even those databases you don't
>> have access to.
>>
>> I believe that in its
On Wed, Feb 3, 2010 at 6:23 AM, Brian Candler wrote:
> I see the readeracl branch was recently merged into trunk, and I've just
> been testing it again.
>
> My concern is that the design is flawed, and that if this goes into 0.11
> then we are stuck with it forever; so it's better to address these
27 matches
Mail list logo
