sin/samba-mirror
1
0
Fork 0
mirror of https://github.com/samba-team/samba.git synced 2024-12-24 21:34:56 +03:00
Code

Put all the protocol stuff into a separate header file.

Browse Source 
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.
This commit is contained in:
Holger Hetterich 2010-02-02 19:36:23 +01:00 committed by Jim McDonough
parent 5b7179d2a3
commit 4940da2e99
2 changed files with 152 additions and 114 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

126
source3/modules/vfs_smb_traffic_analyzer.c
View File

@ -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

140
source3/modules/vfs_smb_traffic_analyzer.h Normal file
View File

@ -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;
};