The user configuration directory can be overridden via environment
variables or configuration files.
In the current implementation `Msf::Config.config_directory` should be
utilized for consistent location reporting. `Msf::Config.get_config_root`
is reserved to generation of a default location and should be considered
`private` as it ignores some injected configuration options. Currently
autoloading does not allow application of the `private` keyword to this method,
requiring guidance during development that module writers should access the
full configured `user` value of `Msf::Config.config_directory`.
MSP-11153
Test the following paths in order and only return them if the path
exists:
1. MSF_DATABASE_CONFIG environment variable
2. ~/.msf4/database.yml
3. <project>/config/database.yml
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.
[#46491831]
Move Msf::DBManager#import_msf_xml into
Msf::DBManager::ImportMsfXml#import_msf_xml and include
Msf::DBManager::ImportMsfXml to cut down size of the infamous db.rb.
Break up #import_msf_xml to have separate methods for parsing web_forms,
web_pages, and web_vulns. The method for
web_vulns, #import_msf_web_vuln_element is needed so that it can be overridden in
Pro to handle the Pro-only changes to Mdm::WebVuln.
Jeffrey Martin