summaryrefslogtreecommitdiff
path: root/source3/modules
diff options
context:
space:
mode:
authorHolger Hetterich <hhetter@novell.com>2010-02-02 19:36:23 +0100
committerJim McDonough <jmcd@samba.org>2010-03-16 09:52:10 -0400
commit4940da2e99647b2d6ae3b4abf78c9904e4390074 (patch)
treeec9be639462d7eac9a0ea7d6507fea33af32ebd9 /source3/modules
parent5b7179d2a3708246c44c5c5126368588f9da74a0 (diff)
downloadsamba-4940da2e99647b2d6ae3b4abf78c9904e4390074.tar.gz
samba-4940da2e99647b2d6ae3b4abf78c9904e4390074.tar.bz2
samba-4940da2e99647b2d6ae3b4abf78c9904e4390074.zip
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.
Diffstat (limited to 'source3/modules')
-rw-r--r--source3/modules/vfs_smb_traffic_analyzer.c126
-rw-r--r--source3/modules/vfs_smb_traffic_analyzer.h140
2 files changed, 152 insertions, 114 deletions
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
diff --git a/source3/modules/vfs_smb_traffic_analyzer.h b/source3/modules/vfs_smb_traffic_analyzer.h
new file mode 100644
index 0000000000..7a3c358a0e
--- /dev/null
+++ b/source3/modules/vfs_smb_traffic_analyzer.h
@@ -0,0 +1,140 @@
+/*
+ * traffic-analyzer VFS module. Measure the smb traffic users create
+ * on the net.
+ *
+ * Copyright (C) Holger Hetterich, 2008
+ * Copyright (C) Jeremy Allison, 2008
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 3 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see <http://www.gnu.org/licenses/>.
+ */
+
+
+/*
+ * Protocol V2.0 definition
+ *
+/
+
+/**
+ * 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;
+};
+
+