SeeRM #8754
Cast the results of the query to an array and perform the uniq
function passing a block which provides uniqueness based
on the return value, which in this instance is ‘fullname’
This was done because the uniq function in AREL cannot take
a specific field for uniqueness, and the sophistication of the query
make grouping nearly impossible. Initial testing showed negligible
speed difference to the user.
[#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.
All Database usage must go through framework.db (which should have been
the case before, anyways) or explicitly checkout and checkin a
connection. Failure to do so causes thread starvation and bizarre
random failures when attempting to use the database.
This commit also explicitly releases database connections at the end of
all threads created via framework.threads.spawn, which should alleviate
Deprecation Warning messages from ActiveRecord.
[Fixes#6613]
nstarke
Tab Assassin
James Lee
Luke Imhoff
HD Moore
sinn3r
scriptjunkie
Tod Beardsley
Samuel Huckins