Auth in mongod 3.6

[m13t]

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 4.1.9
• Ruby: 2.1.9
• Distribution: CentOS/7
• Module version: 2.0.0

How to reproduce (e.g Puppet code you use)

class { '::mongodb::globals':
    bind_ip => [ '0.0.0.0' ],
    version => '3.6.1',
    manage_package_repo => true,
    repo_location => 'https://repo.mongodb.org/yum/redhat/7/mongodb-org/3.6/x86_64/',
  }

  -> class { '::mongodb::client': }

  -> class { '::mongodb::server':
    verbose => true,
    directoryperdb => true,
    manage_pidfile => false,

    auth => true,
    store_creds => true,
    create_admin => true,
    admin_username => "$admin_username",
    admin_password => "$admin_password",
  }

What are you seeing

Debug: Prefetching mongodb resources for mongodb_database
Debug: Executing: '/bin/mongo admin --quiet --host 127.0.0.1:27017 --eval load('/root/.mongorc.js'); printjson(db.getMongo().getDBs())'
Debug: Request failed: 'Execution of '/bin/mongo admin --quiet --host 127.0.0.1:27017 --eval load('/root/.mongorc.js'); printjson(db.getMongo().getDBs())' returned 252: Error: Authentication failed.
2018-01-10T13:35:14.082+0000 E QUERY    [thread1] Error: listDatabases failed:{
	"ok" : 0,
	"errmsg" : "not authorized on admin to execute command { listDatabases: 1.0, $db: \"admin\" }",
	"code" : 13,
	"codeName" : "Unauthorized"
} :
_getErrorWithCode@src/mongo/shell/utils.js:25:13
Mongo.prototype.getDBs@src/mongo/shell/mongo.js:65:1

What behaviour did you expect instead

I would have expected the module to configure Mongo 3.6, enable authentication and create the admin account. It appears the account must be created with mongo running without auth enabled, once an admin account is created, it should be then started with auth enabled.

Output log

As per 'What are you seeing'

Any additional information you'd like to impart

N/A

[miksercz]

Hello,
can confirm that this problem is present on a different configuration too.

Puppet: 5.3.2
Ruby: 2.0.0
Distribution: Ubuntu 14.04.5 LTS
Module version: 2.0.1-rc0

This use-case worked on Puppet 3 with the old module puppetlabs-mongodb: 0.17.0. Unfortunately I can't easily test against a Puppet 3 environment with the current version of the module, but I believe it's something to do with changes in ordering between Puppet 3 and later version.

My code:

class { 'mongodb::client':
  package_name   => 'mongodb-org-shell',
} ->

class { 'mongodb::server':
  bind_ip        => ['0.0.0.0'],
  package_ensure => '3.0.14',
  package_name   => 'mongodb-org-server',
  service_name   => 'mongod',
  create_admin   => true,
  store_creds    => true,
  admin_username => 'root',
  admin_password => 'root',
} 

[nmaludy]

I'm seeing this too.

The only way i can get the error to stop is by setting auth => false

This is affecting the StackStackstorm module puppet-st2: https://github.com/StackStorm/puppet-st2/blob/master/README.md#mongodb-puppet--40-1

========

It looks like the root of the problem is that security.authorization: enabled in /etc/mongod.conf when mongod initially starts. However, when it starts the admin database hasn't been setup with any auth credentials so when commands are attempted to be run, auth fails.

It seems like it needs to run on a first pass with security.authorization: disabled in /etc/mongod.conf, start the mongod service, create the admin database, set security.authorization: enabled, finally restart the service. After this auth can be used and the rest of the commands can execute with auth.

Not sure exactly how to implement this exactly.

[nmaludy]

I have some super hacky code, but it works:

  # define class { 'mongodb':} somewhere before this

  # check if our "custom fact" has been created and set to true
  if $::mongodb_auth_init == undef or $::mongodb_auth_init == false {
    # disable auth
    exec { 'mongodb - stop service':
      command => '/usr/bin/systemctl stop mongod',
      unless  => '/bin/grep "^security.authorization: disabled" /etc/mongod.conf',
    }
    exec { 'mongodb - disable auth':
      command     => '/usr/bin/sed -i \'s/security.authorization: enabled/security.authorization: disabled/g\' /etc/mongod.conf',
      refreshonly => true,
    }
    exec { 'mongodb - auth fact':
      command     => '/usr/bin/echo "mongodb_auth_init: true" > /etc/facter/facts.d/mongodb.yaml',
      refreshonly => true,
    }
    exec { 'mongodb - start service':
      command     => '/usr/bin/systemctl start mongod',
      refreshonly => true,
    }

    # create mongodb admin database with auth disabled

    # enable auth
    exec { 'mongodb - enable auth':
      command => '/usr/bin/sed -i \'s/security.authorization: disabled/security.authorization: enabled/g\' /etc/mongod.conf',
      unless  => '/bin/grep "^security.authorization: enabled" /etc/mongod.conf',
    }
    exec { 'mongodb - restart service':
      command     => '/usr/bin/systemctl restart mongod',
      refreshonly => true,
    }

    # ensure MongoDB config is present and service is running
    Class['mongodb::server::config']
    -> Class['mongodb::server::service']
    # disable auth
    -> Exec['mongodb - stop service']
    ~> Exec['mongodb - disable auth']
    ~> Exec['mongodb - auth fact']
    ~> Exec['mongodb - start service']
    # create mongodb admin database with auth disabled
    -> Mongodb::Db['admin']
    # enable auth
    ~> Exec['mongodb - enable auth']
    ~> Exec['mongodb - restart service']
    -> Mongodb::Db <| title != 'admin' |>
  }

[diranged]

So @nmaludy 's hack works .. but ugh, its not nice to have to do this. Are we all mis-using the code, or is this really a scenario thats just not tested?

[WetHippie]

No, this is correct. I had a patch for the old pre-Voxpopuli takeover of this module that worked correctly. This is a very long-standing bug in the codebase and should be considered top priority. The number of times that data theft has occurred because people configure mongo without authentication is just mind boggling. The defaults should be to have it on and running.

I'll see if I can bring my patch up to date with the latest code and resubmit.

Code is here: https://github.com/WetHippie/puppetlabs-mongodb/tree/admin_user_handling

[trihoangvo]

create_admin uses localhost execeotion to create the first user when "auth" is enabled. Create_admin works with mongo 2.4. However, since 3.0 they changed the localhost exception: "The localhost exception changed so that these connections only have access to create the first user on the admin database. In previous versions, connections that gained access using the localhost exception had unrestricted access to the MongoDB instance."
Thus the command db.getMongo().getDBs() fails.
https://docs.mongodb.com/v3.4/core/security-users/#localhost-exception

[Dharmender-Singh]

I am also facing the same issue. Could you please let me know, when we are planing to fix this.

[ryan-gilligan]

Facing similar issues:

Puppet: 5.5.2
Distribution: RHEL/7.4
Module version: 2.1.2

> mongodb2: Debug: Request failed: 'Execution of '/bin/mongo admin --quiet --host 127.0.0.1:27017 --eval load('/root/.mongorc.js'); printjson(db.getMongo().getDBs())' returned 252: Error: Authentication failed.
>     mongodb2: 2018-06-19T12:31:12.402+0000 E QUERY    [thread1] Error: listDatabases failed:{
>     mongodb2: 	"ok" : 0,
>     mongodb2: 	"errmsg" : "not authorized on admin to execute command { listDatabases: 1.0 }",
>     mongodb2: 	"code" : 13
>     mongodb2: } :

[mstevens-bcs]

I'll leave another 'me too' here. Also note the issues exists when installing MongoDB 4.x, though you get messages similar to this:

Warning: Database creation is available only from master host
Warning: User info is available only from master host
Warning: User creation is available only from master host

I can run the following from a mongo shell to manually create the admin user, but again this is just another hack

use admin db.createUser ( { user: "admin", pwd: "mypassword", roles: [ "userAdminAnyDatabase", "dbAdminAnyDatabase", "readWriteAnyDatabase" ] } )

Is this on the radar for a fix?

[negast]

I'm working with puppet5 and mongodb 4.0.8
Following fork fixed this for me: https://github.com/datty/puppet-mongodb

Note that in this fork your admin user has to be named admin in order to use the create_adminuser function. I created a subfork to only do this for the database named admin.
original: https://github.com/datty/puppet-mongodb
mySubFork: https://github.com/negast/puppet-mongodb

[identw]

Another crutch that solves this problem for me, may be useful to someone:

    class {'mongodb::globals':
        manage_package_repo => true,
        version             => '3.6.12',
    }
    -> class {'mongodb::client': }
    -> class {'mongodb::server':
        auth                => true,
        create_admin        => true,
        admin_username      => 'root',
        admin_password      => 'password',
        store_creds         => true,
        bind_ip             => ['127.0.0.1']
    }


   exec {'mongodb_auth_fix_disable_auth':
        command => "sed -i 's/security.authorization: enabled/security.authorization: disabled/' /etc/mongod.conf; touch /root/.mongodb_auth_fix_disable_auth",
        path    => ['/bin', '/usr/bin'],
        notify  => [
            Class['mongodb::server::service'],
        ],
        creates => '/root/.mongodb_auth_fix_disable_auth',
        require => Class['mongodb::server::config'],
    }

    mongodb::db { 'db_name':
        user          => 'db_user',
        password      => 'db_pass',
    } ->

    exec {'mongodb_auth_fix_enable_auth':
        command => "sed -i 's/security.authorization: disabled/security.authorization: enabled/' /etc/mongod.conf; systemctl restart mongod; touch /root/.mongodb_auth_fix_enable_auth;",
        path    => ['/bin', '/usr/bin'],
        creates => '/root/.mongodb_auth_fix_enable_auth',
    }

[mungo312]

Are there any efforts to fix this ? Maybe integrate the fork ?

[fduranti]

Any news on resolution or a good workaround of this bug?

[jc16180]

Bumping this issue as still an open problem in the latest version of the puppet module.