[SERVER-17717]  security.authorization: disabled does not work in 3.01 Created: 24/Mar/15  Updated: 30/Mar/15  Resolved: 24/Mar/15

Status: Closed
Project: Core Server
Component/s: Security
Affects Version/s: 3.0.1
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Daniel Sidman Assignee: Andreas Nilsson
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Operating System: ALL
Steps To Reproduce:

use this config file then try to create a user:

storage:
dbPath: "c:/data"
journal:
enabled: true
systemLog:
destination: file
path: "C:/mongologs/mongodb.log"
logAppend: true
net:
bindIp: 11.1.1.2
port: 27017
http.enabled: true
http.RESTInterfaceEnabled : true
security:
authorization: disabled
replication:
oplogSizeMB: 10240
replSetName: "rs1"

Sprint: Security 1 04/03/15
Participants:

 Description   

Hi,
I am flagging this as a bug, as the mongod dev user google is full of people having problems with the 3.01 security configuration. People can't get into the web console or list databases or list users because of this bug. My hypothesis is when the disable auth option went away the replacement authorization is faulty. Here is my configuration file, using this I can connect but can't access the test db or admin db or create a user..or use webadmin

storage:
dbPath: "c:/data"
journal:
enabled: true

systemLog:
destination: file
path: "C:/mongologs/mongodb.log"
logAppend: true

net:
bindIp: 11.1.1.2
port: 27017
http.enabled: true
http.RESTInterfaceEnabled : true

security:
authorization: disabled

replication:
oplogSizeMB: 10240
replSetName: "rs1"



 Comments   
Comment by Andreas Nilsson [ 24/Mar/15 ]

No problem!

Comment by Daniel Sidman [ 24/Mar/15 ]

I found the problem, the replication setting made it a secondary server....not the master, that is why I could not do mongo operations.

Please close the ticket. Thanks for your help!

Comment by Andreas Nilsson [ 24/Mar/15 ]

There was a regression bug introduced in 3.0.1 with regards to the web interface prompting for user name and password when it need not. This has been fixed in the master branch.

As for the shell I haven't heard any other complaints. You can bootstrap the auth system either by:
1. starting mongod without the --auth flag/authorization: enabled in which case all permissions should be open.
2. starting with access control enabled and use the localhost exception to create your first admin user. Once that user has been created you will need to login with that user to perform subsequent operations.

If you can't get it to work, can you provide your configuration file and your mongod/mongo command line arguments and I will have a look at it.

Regards,
Andreas

Comment by Daniel Sidman [ 24/Mar/15 ]

Hi,
Thanks for you quick response. Much appreciated.
I am trying this now with a new install of 3.01. It seems to be a permission issue.
I thought with
security:
authorization: disabled

I should be able to connect with the mongo shell and be able to create users, just like using the legacy --noauth option for starting the server. I can connect but have no rights. I was trying to use the admin page as a work-around but it prompts for a username and password.

My goal is just to create some users. This is an install and config issue, but I thought since so many people were having it, there was a bug?

Comment by Andreas Nilsson [ 24/Mar/15 ]

Thanks for your report heropurpose

I believe the issues you mention above are different. The issue with the web console is addressed in SERVER-17669 but web console auth is only supported for MONGODB-CR and not the newer SCRAM-SHA-1 protocol. We disencourage use of the web console except for backwards compatibility purposes.

Can you elaborate on the exact problems you have seen with list databases and list users.

Thank you,
Andreas

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