On Tue, Feb 16, 2010 at 3:12 AM, Brian Candler <[email protected]> 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:[email protected]: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
