J'ai fouillé Config.cpp
, le fichier responsable de l'analyse de la configuration. L'exemple de configuration fait en fait un très bon travail de capture des options disponibles - il n'y en a pas beaucoup
Quand je me réfère à "l'exemple de sortie" ci-dessous, je parle de cette ligne (tirée au hasard de la page d'exemple):
17:29:35 (src/loggedfs.cpp:136) getattr /var/ {SUCCESS} [ pid = 8700 kded [kdeinit] uid = 1000 ]
La balise racine est <loggedFS>
. Il a deux attributs facultatifs:
- logEnabled est une chaîne - "true" signifie qu'il doit réellement afficher les informations de journal; toute autre chose désactive toute la journalisation. Par défaut "vrai", car c'est en quelque sorte tout l'intérêt du programme
- printProcessName est une chaîne - "true" signifie que la sortie du journal inclura le nom du processus, tout le reste signifie que non. Par défaut "vrai". Dans l'exemple de sortie,
kded [kdeinit]
est le nom du processus
Les seuls nœuds enfants dont il se soucie sont <include>
et <exclude>
. Dans l'exemple, ils regroupent les sous <includes>
et les <excludes>
blocs, mais ceux-ci sont ignorés par l'analyseur (comme tous les autres nœuds sauf <include>
et <exclude>
).
Naturellement, les <include>
règles le forcent à afficher la ligne de journal si elles correspondent, tandis que les <exclude>
lignes ne le font pas. En cas de chevauchement, <exclude>
annule <include>
. Normalement, vous avez besoin d'au moins une <include>
règle pour correspondre à un événement à enregistrer, mais une exception est s'il y a 0 <include>
règles - alors tous les événements sont enregistrés, même s'il y a des <exclude>
lignes correspondantes .
Les deux <include>
et <exclude>
prennent les mêmes attributs:
- L'extension est une expression régulière qui est comparée au chemin absolu du fichier qui a été consulté / modifié / peu importe (
extension
c'est un nom plutôt médiocre, mais je suppose que c'est l'usage courant). Par exemple, si vous touch /mnt/loggedfs/some/file
, l'expression régulière dans extension
devrait correspondre (partiellement)/mnt/loggedfs/some/file
- uid est une chaîne qui contient un entier ou
*
. La règle ne correspond à une opération donnée que si le propriétaire du processus qui a provoqué l'opération a l'ID utilisateur spécifié ( *
signifie naturellement que n'importe quel ID utilisateur correspond). Dans l'exemple de sortie, 1000
est l'uid
- action est le type spécifique d'opération effectuée sur le système de fichiers. Dans l'exemple de sortie,
getattr
est l'action. Les actions possibles sont:
- accès
- chmod
- chown
- getattr
- lien
- mkdir
- mkfifo
- mknod
- ouvert
- en lecture seule
- open-readwrite
- open-writeonly
- lis
- readdir
- lien de lecture
- Renommer
- rmdir
- statfs
- lien symbolique
- tronquer
- dissocier
- utime
- spécimens
- écrire
- retname est une expression régulière. Si le code retour de l'opération de système de fichiers réelle effectuée par LoggedFS est 0, l'expression régulière est comparée à la chaîne
SUCCESS
. Un code retour différent de zéro le fait correspondre FAILURE
. Ce sont les seules valeurs possibles, donc plus probable que vous êtes soit aller à hardcode SUCCESS
, FAILURE
ou l' utilisation .*
si vous voulez à la fois. Dans l'exemple de sortie, SUCCESS
est leretname
Contrairement aux <loggedFS>
attributs, ceux-ci n'ont pas de valeurs par défaut. De plus, bien que l'analyseur reconnaisse les attributs inconnus et les erreurs, il ne détecte pas les attributs manquants, donc si vous oubliez un attribut, il utilisera de la mémoire non initialisée.
/a
, excluez/a/b
et incluez/a/b/c
, est/a/b/c
regardé? L'inclusion d'un répertoire inclut-elle toujours son contenu?<include extension="/a" uid="*" action=".*" retname=".*" />
correspondre à chaque opération qui opère sur un fichier dont le chemin contient/a
- cela pourrait même être/foo/abc/bar
. Vous voulez probablement les ancrer tous avec^
et$
, mais vous devez ensuite inclure le chemin complet pour qu'il corresponde