MSP-9653
Calling `ActiveRecord::Base.establish_connection`, followed by
`ActiveRecord::Base.connected?` returns false unless some other code
requires a connection to be checked out first. The correct way to check
if the spec passed to `ActiveRecord::Base.establish_connection` is to
checkout a connection and then ask if it is active.
`Msf::DBManager#connection_established?` does the checkout, active check
and checkin, and should be used in place of
`ActiveRecord::Base.connected?` and
`ActiveRecord::Base.connection_pool.connected?`.
`Msf::DBManager#active` should still be used as it also checks for
adapter/driver usability and that migrations have run.
MSP-9653
If ActiveRecord::Base is already connected, then don't attempt to create
the database (as it involves establishing a new connection) or
establishing a new connection after the creation. Still run the
migrations as the normal Rails::Application.initialize! will result in
ActiveRecord::Base.connected? being true even if migrations are missing.
MSP-9606
Catch LoadError in config/application.rb when trying to require
'active_record/railtie` so that end-users can run without any of the
database gems installed. NOTE: you can't run in the development or
test environment without the database because factory_girl needs
ActiveRecord.
MSP-9606
In order to support Metasploit::Credential correctly,
metasploit-framework needs to support Metasploit::Concern, which does
all its magic using a Rails::Engine initializer, so the easiest path is
to make metasploit-framework be able to use Rails::Engines. To make
Rails::Engine use Rails::Engine, make a dummy Rails::Application
subclass so that all the initializers will be run when anything requires
msfenv.
[#50179803]
Move Msf::DBManager#migrate and the migrated attribute to
Msf::DBManager::Migration module to lower complexity of db_manager.rb
and in preparation for more migration related code on this branch.
[#50099107]
If Msf::DBManager#initialize_metasploit_data_models is run multiple
times, such as during specs, ActiveRecord::Migrator.migrations_paths was
getting populated with multiple copies of the metasploit_data_models
db/migrate path, which would lead to 'DB.migrate threw an exception:
Multiple migrations have the version number 0' errors in framework.log.
[#44034071]
ActiveRecord::Migrator has a class attribute, migrations_paths,
specificially for storing a list of different directories that have
migrations in them. ActiveRecord::Migrator.migrations_paths is used in
rake db:load_config, which is a dependency of db:migrate, etc. that is
passed to ActiveRecord::Migrator.migrate. Since migrate supports an
array of directories, and not just a single directory, there is no need
to merge all the migrations paths into one temporary directory as was
previously done.
[#44034071]
metasploit_data_models version 0.5.0 copied the migrations from
metasploit-framework/data/sql/migrate to
metasploit_data_models/db/migrate so that specs could be written the Mdm
models in metasploit_data_models. As part of the specs, :null => false
columns that should be :null => true were discovered, so a new migration
was added, but to metasploit_data_models/db/migrate, so it could be
tested. Instead of replicating migrations back and forth, I'm removing
the migrations completely from metasploit-framework and changing the
default migration path in Msf::DbManager#migration_paths to
MetasploitDataModels.root.join('db', 'migrate').
When db_disconnect is issued, this funtion does not update the status
of self.migrated to false. So when another reload command is used,
the update_module_details function will still try to connect to the
database, which causes the "Failed to reload" error.
Instead of deleting all non-symbolics before the re-adding phase of
PayloadSet#recalculate, store a list of old module names, populate a
list of new ones during the re-adding phase, and finally remove any
non-symbolic module that was in the old list but wasn't in the new list.
Also includes a minor refactoring to make ModuleManager its own thing
instead of being an awkard subclass of ModuleSet. Now PayloadSet doesn't
need to know about the existence of framework.modules, which makes the
separation a little more natural.
[FixRM #7037]
Ensures that the absence of activerecord does not prevent msfconsole
from loading. This returns us to the previous state of affairs where it
is possible to use the framework entirely without a database.
To test:
1. rm -rf lib/gemcache/ruby/1.9.1/gems/activerecord*
2. remove any locally installed versions of activerecord
3. msfconsole
msfconsole should load up with a warning like so:
[-] ***
[-] * WARNING: No database support: LoadError cannot load such file -- active_record
[-] ***
... and should still be functional.
I missed a spot where I referenced the nested_paths as nested_pathnams
after I renamed the variable. Now, Msf::ModuleManager#add_module_paths
has rspec tests.
Rspec can be invoked with `rake` as the default task or `rake spec`
explicitly.
I changed RuntimeError to ArgumentError since that error was more
specific to having a bad argument error. I adding missing dependencies
to the Gemfile and a require to msf/core/db_manager.rb where it errored
out trying to access Msf::Config when I just did require 'msf/core' in
the spec.
Luke Imhoff
Tab Assassin
James Lee
HD Moore
sinn3r
scriptjunkie
Tod Beardsley
Samuel Huckins