The database layer for Metasploit
MsfModels exists to do several key things:
Allow code sharing between Metasploit Framework (MSF) and the commercial versions of Metasploit (Community, Express, Pro -- usually referred to collectively as "Pro")
Create an easy-to-use mechanism to guide the future development of both commercial and FOSS features.
(FUTURE) Give FOSS developers a lightweight entry point to MSF's backend for use in developing lightweight tools that gather data intended for later use with MSF (e.g. specialized scanners).
When MsfModels is included by a Rails application, it simply makes mixins available to ActiveRecord models that provide high-level behavior for those models. After performing the top-level include in an initializer, we mixins in an appropriate module from msf_models for each model that is shared.
When MsfModels is included by MSF, the gem dynamically creates ActiveRecord model classes.
Both of these behaviors are based on the assumption that the files in lib/msf_models/active_record_models, though implemented here as mixins, actually represent the ActiveRecord models that both MSF and Pro use.
Because the gem is defining mixins, there can be no knowledge of the specifics of any "current" ActiveRecord connection. But if ActiveRecord encounters something in a child class that would require knowledge of the connection adapter (e.g. the use of an RDBMS-specific function in a named scope's "WHERE" clause), it will check to see if the adapter supports it and then throw an exception when the connection object (which provides the adapter) is nil.
You'll encounter this sometimes as you add things to this gem. A good rule of thumb: anything that goes into the class_eval block must be able to work without knowledge of the AR connection type.