1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
|
# Internals - Snoopy Command Logger
## How does Snoopy actually work?
Snoopy installs itself as a preloaded library that provides a wrapper
around execv() and execve() syscall. Logging is done via syslog.
Snoopy should be completely transparent to users and to applications.
## Architectural note
execv() calls are now explicitly logged. Although, according to the
man page for execv(), it is supposed to call execve(). To this date
the reason why execv() calls weren't being logged is unknown, but we
are working to find out why.
## Further information
* Read the code.
* Start at [src/entrypoint/execve-wrapper.c](../src/entrypoint/execve-wrapper.c).
This part is essential.
Here, the execv()/execve() syscalls are intercepted and forwarded to internal
Snoopy functions. Once Snoopy's logging work is done, execution is forwarded
back to the real execv()/execve() syscall.
* Continue with [src/action/log-syscall-exec.c](../src/action/log-syscall-exec.c),
[src/message.c](../src/message.c) and [src/action/log-message-dispatch.c](../src/action/log-message-dispatch.c).
Here you can learn how a Snoopy log message is generated (using data sources)
and dispatched to the configured output.
* Configuration file parsing code is here: [src/configfile.c](../src/configfile.c)
* Data sources are located here: [src/datasource/](../src/datasource/)
* Filters are located here: [src/filter/](../src/filter/)
* Outputs are located here: [src/output/](../src/output/)
## Data storage list
When thread safety is DISABLED (default), data is stored in the following global
variables:
- snoopy_configuration_data
- snoopy_inputdatastorage_data
These variables must not be accessed directly, but rather by their corresponding
snoopy_*_get() functions. These functions, when thread safety is enabled, return
pointers to thread-specific instances of these variables.
When thread-safety is enabled, all configuration data is stored in single global
registry, and its structure looks something like this:
- *tsrm_threadRepo (of type List ptr):
- main threadRepo/list data structure
- the only production global variable (there is another for testing purposes - altConfigFilePath)
- malloced in tsrm_ctor(), if necessary, with mutex
- freed in tsrm_dtor(), if necessary, with mutex
- *firstNode (null or ListNode ptr)
- *lastNode (null or ListNode ptr): pointer to tsrm_threadRepo's last node
- ListNode structure:
- *prevNode
- *nextNode
- *value: pointer to malloced tsrm_threadData_t
- (*value structure):
- (malloced in tsrm_createNewThreadData())
- tid (id of thread for this threadData
- *configuration : malloced in tsrm_createNewThreadData()
- *inputdatastorage: malloced in tsrm_createNewThreadData()
- (*configuration structure):
- defaults in configuration_setDefaults()
- see structure in configuration.h
- (*inputdatastorage structure):
- defaults in inputdatastorage_setDefaults()
- see structure in inputdatastorage.h
- *argv
- *envp
|
