From 4940da2e99647b2d6ae3b4abf78c9904e4390074 Mon Sep 17 00:00:00 2001 From: Holger Hetterich Date: Tue, 2 Feb 2010 19:36:23 +0100 Subject: Put all the protocol stuff into a separate header file. All the structures and the vfs function identifier list is required by the receiver. It's therefore very handy to have this in an extra header file. --- source3/modules/vfs_smb_traffic_analyzer.c | 126 +++-------------------------- 1 file changed, 12 insertions(+), 114 deletions(-) (limited to 'source3/modules/vfs_smb_traffic_analyzer.c') diff --git a/source3/modules/vfs_smb_traffic_analyzer.c b/source3/modules/vfs_smb_traffic_analyzer.c index 4465425927..7d7332e1b9 100644 --- a/source3/modules/vfs_smb_traffic_analyzer.c +++ b/source3/modules/vfs_smb_traffic_analyzer.c @@ -21,123 +21,13 @@ #include "includes.h" #include "../lib/crypto/crypto.h" +#include "vfs_smb_traffic_analyzer.h" /* abstraction for the send_over_network function */ enum sock_type {INTERNET_SOCKET = 0, UNIX_DOMAIN_SOCKET}; #define LOCAL_PATHNAME "/var/tmp/stadsocket" - -/** - * Protocol version 2.0 description - * - * The following table shows the exact assembly of the 2.0 protocol. - * - * -->Header<-- - * The protocol header is always send first, and contains various - * information about the data block to come. - * The header is always of fixed length, and will be send unencrypted. - * - * Byte Number/Bytes Description - * 00-02 Contains always the string "V2." - * 03 This byte contains a possible subrelease number of the - * protocol. This enables the receiver to make a version - * check to ensure the compatibility and allows us to - * release 2.x versions of the protocol with bugfixes or - * enhancements. - * 04 This byte is reserved for possible future extensions. - * 05 Usually, this byte contains the character '0'. If the - * VFS module is configured for encryption of the data, - * this byte is set to 'E'. - * 06-09 These bytes contain the character '0' by default, and - * are reserved for possible future extensions. They have - * no function in 2.0. - * 10-27 17 bytes containing a string representation of the - * number of bytes to come in the following data block. - * It is right aligned and filled from the left with '0'. - * - * -->Data Block<-- - * The data block is send immediately after the header was send. It's length - * is exactly what was given in bytes 11-28 from in the header. - * - * The data block may be send encrypted. - * - * To make the data block easy for the receiver to read, it is divided into - * several sub-blocks, each with it's own header of four byte length. In each - * of the sub-headers, a string representation of the length of this block is - * to be found. - * - * Thus the formal structure is very simple: - * - * [HEADER]data[HEADER]data[HEADER]data[END] - * - * whereas [END] is exactly at the position given in bytes 11-28 of the - * header. - * - * Some data the VFS module is capturing is of use for any VFS operation. - * Therefore, there is a "common set" of data, that will be send with any - * data block. The following provides a list of this data. - * - the VFS function identifier (see VFS function ifentifier table below). - * - a timestamp to the millisecond. - * - the username (as text) who runs the VFS operation. - * - the SID of the user who run the VFS operation. - * - the domain under which the VFS operation has happened. - * - */ - - -/** - * VFS Functions identifier table. In protocol version 2, every vfs - * function is given a unique id. - */ -enum vfs_id { - /* - * care for the order here, required for compatibility - * with protocol version 1. - */ - vfs_id_read, - vfs_id_pread, - vfs_id_write, - vfs_id_pwrite, - /* end of protocol version 1 identifiers. */ - vfs_id_mkdir, - vfs_id_rmdir, - vfs_id_rename, - vfs_id_chdir -}; - -/* - * Specific data sets for the VFS functions. - * A compatible receiver has to have the exact same dataset. - */ -struct mkdir_data { - const char *path; - mode_t mode; - int result; -}; - -struct rmdir_data { - const char *path; - int result; -}; - -struct rename_data { - const char *src; - const char *dst; - int result; -}; - -struct chdir_data { - const char *path; - int result; -}; - -/* rw_data used for read/write/pread/pwrite */ -struct rw_data { - char *filename; - size_t len; -}; - static int vfs_smb_traffic_analyzer_debug_level = DBGC_VFS; static enum sock_type smb_traffic_analyzer_connMode(vfs_handle_struct *handle) @@ -277,13 +167,21 @@ static char *smb_traffic_analyzer_create_string( struct tm *tm, \ char *usersid = NULL; const char *total_anonymization = NULL; const char *anon_prefix = NULL; + /* + * first create the data that is transfered with any VFS op + * These are, in the following order: + * number of data to come [6 in v2.0] + * 1.vfs_operation identifier + * 2.username + * 3.user-SID + * 4.affected file + full path + * 5.domain + * 6.timestamp + */ - /* first create the data that is transfered with any VFS op */ opstr = talloc_asprintf(talloc_tos(), "%i", vfs_operation); len = strlen(opstr); buf = talloc_asprintf(talloc_tos(), "%04u%s", len, opstr); - len = strlen( username ); - buf = talloc_asprintf_append(buf, "%04u%s", len, username); /* * Handle anonymization. In protocol v2, we have to anonymize -- cgit