Re: configure and mySQL Database

William Heinbockel wrote:
> The best option to incorporate multiple databases is to write libraries
> that Nessus can use for the database calls.  If people want to write
> database specific code (similar to the code I have for mySQL), it can 
> easily be incorporated into the server code.  That is why we need to
> iron out a common schema so that all of the database calls through
> Nessus are similar.

I think that the code you are writting provides the common functions all 
database stubs should include. SQL calls should probably be more or less 
the same, so I believe your code could be used as a common base. I'm 
thinking something along the lines of :

update_plugin( struct arglist * globals, char * plugin_id, char * ip, 
char * status )
{
#ifdef USE_MYSQL
   MYSQL * conn = (MYSQL *)arg_get_value( globals, "mysql" );
#endif
#ifdef USE_POSTGRESQL
   PSQL * conn = (PSQL *) arg_get_value( globals, "postgresql" );
#endif
   char * session_id = (char *)arg_get_value( globals, "SESSION_ID" );
(...)
     sprintf( query, "UPDATE Host SET Status=\"%s\" WHERE Host_IP=\"%s\" 
AND SessionID=\"%s\" AND PluginID=\"%s\"", status, host_ip, session_id, 
plugin_id );
#ifdef USE_MYSQL
     mysql_escape_string( to_send, query, strlen( query ));
     mysql_query( conn, to_send );
#endif USE_MYSQL
#ifdef USE_POSTGRESL
     postgresql_escape_string( to_send, query, strlen( query ));
     postgresql_query (conn, to_send);
#endif
(...)


Note that the call gets made to update_plugin and not 
mysql_update_plugin. Since the SQL query is probably going to be the 
same across all databases it makes sense to make it this way. Doesn't it?

That way only the calls specific to a given database (retrieve the 
handle for connection to it, make the sql query...) are done through 
function calls specific to the database while the other functions are 
common to all databases. From your save_mysql.c code: create_host_table, 
create_detected_services_table, create_vulnerability_table, 
create_session_table, create_exec_plugins_table, create_tables, 
open_connection, new_scan_session, scan_session_complete, new_host_scan, 
close_connection, update_host_scan, new_plugin, and update_plugin.

> 
> I agree that the code should be initially compiled with the preprocessor
> directives, so that only the necessary code and C APIs are compiled in.
> That's why the stuff needs put into the configure script.  The necessary
> APIs need to be present and their exact location needs to be given to
> the compiler.  Versions and other items might need to be checked to verify
> that the API will work with the Nessus DB code.

	Yes, we probably have to decide a version for each database schema. 
This version should be included in the script that created the database 
the first time and the DB code should check wether it's the same they 
are expecting. That way we shouldn't have problems when we update the 
schema and people are using old databases.


> Also, it might be useful to put in code to the Preferences and Rules so
> that an admin can control who can use the database and they could run
> Nessus without storing the results to the DB.

	Yes. That's an interesting feature, hadn't thought of it.

Regards

	Javi