incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <jch...@apache.org>
Subject Re: DB ACLs (was Re: 0.11 Release / Feature Freeze for 1.0)
Date Tue, 16 Feb 2010 17:56:57 GMT
On Tue, Feb 16, 2010 at 3:12 AM, Brian Candler <B.Candler@pobox.com> 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_ctx=#user_ctx{name=Name,roles=Roles}}=Db)
->
>     AdminRoles -> % same list, not an admin role
>         case AdminNames -- [Name] of
>         AdminNames -> % same names, not an admin
> -            throw({unauthorized, <<"You are not a db or server admin.">>});
> +            %% throw({unauthorized, <<"You are not a db or server admin.">>});
> +            Msg = list_to_binary(io_lib:format("Bah. Admins=~p, AdminNames=~p,
AdminRoles=~p, Name=~p, Roles=~p", [Admins, AdminNames, AdminRoles, Name, Roles])),
> +            throw({unauthorized, Msg});
>         _ ->
>             ok
>         end;
> @@ -273,12 +275,15 @@ check_is_reader(#db{user_ctx=#user_ctx{name=Name,roles=Roles}=UserCtx}=Db)
->
>     end.
>
>  get_admins(#db{security=SecProps}) ->
> -    proplists:get_value(<<"admins">>, SecProps, {[]}).
> +    Admins = proplists:get_value(<<"admins">>, SecProps, {[]}),
> +    ?LOG_INFO("In get_admins: SecProps=~p Admins=~p", [SecProps, Admins]),
> +    Admins.
>
>  get_readers(#db{security=SecProps}) ->
>     proplists:get_value(<<"readers">>, SecProps, {[]}).
>
>  get_security(#db{security=SecProps}) ->
> +    ?LOG_INFO("In get_security: SecProps=~p", [SecProps]),
>     {SecProps}.
>
>  set_security(#db{update_pid=Pid}=Db, {NewSecProps}) when is_list(NewSecProps) ->
>
> Results:
>
> [Tue, 16 Feb 2010 10:54:12 GMT] [info] [<0.94.0>] In get_admins: SecProps=[{admins,{[{names,[<<"brianadmin">>]},{roles,[]}]}},
>                         {readers,{[{names,[]},{roles,[]}]}},
>                         {sec_obj,{[{<<"foo">>,<<"bar">>}]}}]
Admins={[]}
>
> [Tue, 16 Feb 2010 10:54:12 GMT] [info] [<0.94.0>] In get_security: SecProps=[{admins,{[{names,[<<"brianadmin">>]},{roles,[]}]}},
>                           {readers,{[{names,[]},{roles,[]}]}},
>                           {sec_obj,{[{<<"foo">>,<<"bar">>}]}}]
>
> [Tue, 16 Feb 2010 10:54:12 GMT] [info] [<0.94.0>] 127.0.0.1 - - 'GET' /briantest/_security
200
>
> [Tue, 16 Feb 2010 10:54:25 GMT] [info] [<0.106.0>] In get_admins: SecProps=[{admins,{[{names,[<<"brianadmin">>]},{roles,[]}]}},
>                         {readers,{[{names,[<<"brian">>]},{roles,[]}]}},
>                         {sec_obj,{[]}}] Admins={[]}
>
> [Tue, 16 Feb 2010 10:54:25 GMT] [info] [<0.106.0>] In get_admins: SecProps=[{admins,{[{names,[<<"brianadmin">>]},{roles,[]}]}},
>                         {readers,{[{names,[]},{roles,[]}]}},
>                         {sec_obj,{[{<<"foo">>,<<"bar">>}]}}]
Admins={[]}
>
> [Tue, 16 Feb 2010 10:54:25 GMT] [info] [<0.106.0>] In get_admins: SecProps=[{admins,{[{names,[<<"brianadmin">>]},{roles,[]}]}},
>                         {readers,{[{names,[]},{roles,[]}]}},
>                         {sec_obj,{[{<<"foo">>,<<"bar">>}]}}]
Admins={[]}
>
> [Tue, 16 Feb 2010 10:54:25 GMT] [info] [<0.106.0>] 127.0.0.1 - - 'PUT' /briantest/_design/foo
401
>
> The problem is that in my database, SecProps has atom admins as the proplist
> key, but get_admins is looking for binary <<"admins">> as the key.
>
> However, on a freshly-created database, binaries *are* used as keys:
>
> [Tue, 16 Feb 2010 10:59:05 GMT] [info] [<0.126.0>] In get_security: SecProps=[{<<"admins">>,
>                            {[{<<"names">>,[<<"brianadmin">>]},
>                              {<<"roles">>,[]}]}},
>                           {<<"readers">>,
>                            {[{<<"names">>,[]},{<<"roles">>,[]}]}},
>                           {<<"sec_obj">>,{[{<<"foo">>,<<"bar">>}]}}]
>
> [Tue, 16 Feb 2010 10:59:05 GMT] [info] [<0.126.0>] 127.0.0.1 - - 'GET' /testdb/_security
200
>
> and I realised I could fix the problem by a GET followed by a PUT of the
> _security document.
>
> $ curl http://127.0.0.1:5984/briantest/_security | curl -X PUT --data-binary @- http://admin:admin@127.0.0.1:5984/briantest/_security
>
>
> So I would summarise this as:
>
> (1) whatever mechanism merged my old _readers and _admins into _security got
> it wrong (but I haven't found that mechanism yet)
>
> (2) the code which retrieves _security and returns it as JSON to the browser
> is unable to distinguish atoms from binaries, and so it gives a false
> impression to the user that the security settings have been set in a
> particular way, when they have not.
>

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. Also, I think very few people defined db-admins prior to 0.11.

> I don't know if this is worth opening a JIRA ticket for, because maybe it
> only affects databases which have been following trunk.  But anything which
> means that security behaves differently to how it appears to have been
> configured makes me nervous.
>
> Regards,
>
> Brian.
>



-- 
Chris Anderson
http://jchrisa.net
http://couch.io

Mime
View raw message