[SERVER-4265] Can't write to local database on a secondary if using --auth Created: 11/Nov/11  Updated: 30/Mar/12  Resolved: 23/Nov/11

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: 2.0.1
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Chris Westin Assignee: Kristina Chodorow (Inactive)
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-4264 add option to map/reduce output to ou... Closed
Participants:

 Description   

Without --auth:

connecting [with auth] to: localhost:27888/admin
testReplSet:SECONDARY> use local
switched to db local
testReplSet:SECONDARY> db.y.save(

{"whee":1}

)
testReplSet:SECONDARY> db.y.find()

{ "_id" : ObjectId("4ebced0bf3ff493b2fe7c468"), "whee" : 1 }

With --auth:

connecting [with auth] to: localhost:27888/flomeromity
testReplSet:SECONDARY> use local
switched to db local
testReplSet:SECONDARY> db.z.save(

{"whee":1}

)
unauthorized
testReplSet:SECONDARY> db.z.find()
error: {
"$err" : "unauthorized db:local lock type:-1 client:127.0.0.1",
"code" : 10057
}



 Comments   
Comment by Eliot Horowitz (Inactive) [ 23/Nov/11 ]

With --auth - access to local should definitely be restricted.

Comment by T. Dampier [ 23/Nov/11 ]

Sorry, I think the description was unclear on an important point. I agree that when authenticated as an 'admin' user, this works exactly as Kristina demonstrates.

But a NON-admin user – e.g., a user authenticated to the 'flomeromity' database in the example below – is unable to acquire the privilege to work with 'local'.

Having said that, I can immediately see the argument for closing this issue as "working as designed" : why should a user of db 'foo' be able to muck with db 'local' any more than he would be able to muck with db 'bar'? If user wants to use 'local', user must be able to auth to 'local' (or, of course, to 'admin').

(7)[15:55]t0d-13:~> mongo localhost:27887/flomeromity                  
MongoDB shell version: 1.8.2
connecting to: localhost:27887/flomeromity
testReplSet:PRIMARY> db.auth( "flume", "flume" )
1
testReplSet:PRIMARY> // now able to do things on 'flomeromity' db ... 
testReplSet:PRIMARY> db.whoopee.find()
{ "_id" : ObjectId("4eb838da9e7e01922ae03c54"), "whee" : "asdfasdfasdfasdf" }
{ "_id" : ObjectId("4eb838e39e7e01922ae03c55"), "whee" : "asdfqqqqqqqqqqqqqqasdfasdfasdf" }
{ "_id" : ObjectId("4eb838ed9e7e01922ae03c56"), "whee" : "asdfjjjjjjjjjjjjjqqqqqqqqqqqqqqasdfasdfasdf" }
{ "_id" : ObjectId("4eb839049e7e01922ae03c57"), "whee" : "beep boop beep" }
testReplSet:PRIMARY> 
testReplSet:PRIMARY> // but will not be able to mess with 'local' db ...
testReplSet:PRIMARY> use local
switched to db local
testReplSet:PRIMARY> db.foo.find()
error: {
        "$err" : "unauthorized db:local lock type:-1 client:127.0.0.1",
        "code" : 10057
}
testReplSet:PRIMARY> 

Comment by Kristina Chodorow (Inactive) [ 21/Nov/11 ]

Did you log in first? It works for me if I log in:

local> // can't query/insert
local> db.foo.find()
error: {
        "$err" : "unauthorized db:local lock type:-1 client:127.0.0.1",
        "code" : 10057
}
local> // log in
local> use admin
switched to db admin
admin> db.auth("foo","bar")
1
admin> // now it works
admin> use local
switched to db local
local> db.foo.find()
{ "_id" : ObjectId("4ecaadec969f464f62fcf577"), "x" : 1 }
local> db.foo.insert({x:1})
admin>

Generated at Thu Feb 08 03:05:29 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.