Fichiers disparaissant sur le serveur Linux

J'ai 4 fichiers spécifiques qui semblent continuer à disparaître du répertoire personnel d'un utilisateur. À notre connaissance, il n'y a pas de tâches cron ou d'autres tâches automatisées qui les supprimeraient. J'ai configuré auditd sur eux, mais les journaux ne montrent vraiment rien d'intéressant. Je peux voir notre utilitaire de sauvegarde y accéder tous les soirs jusqu'à ce qu'ils ne soient plus là, mais rien d'autre. Y a-t-il quelque chose qui entraînerait la suppression de ces fichiers qui contournerait auditd?

Les fichiers en question sont les suivants:

/home/username/.bashrc
/home/username/.bash_profile

ainsi que quelques fichiers dans le répertoire .ssh de cet utilisateur. Les copies de ces fichiers placées dans un sous-dossier appelé «gardiens» sont également supprimées en même temps. Changer les autorisations sur 000 et les faire appartenir à root n'a pas aidé.

J'ai actuellement une configuration inotifywait pour créer, supprimer, déplacer ce sous-dossier, donc j'espère que cela va produire quelque chose, bien qu'il ne se connecte pas beaucoup en dehors du moment où il s'est produit, pas de la cause.

Solution 1 : systemtap
Vous pouvez utiliser systemtap pour afficher tous les PID qui tentent d'utiliser unlink () sur l'inode de .bashrcet les .bash_profilefichiers.

Installez systemtap et les symboles de débogage pour votre noyau.

Créez un fichier avec un nom unlink.stapavec le contenu suivant:

probe syscall.unlink
{
    printf ("%s(%d) unlink (%s) userID(%d)\n", execname(), pid(), argstr, uid())
}

Ensuite, exécutez-le avec sudo stap unlink.stap

Solution 2 : inotify
Vous pouvez également utiliser inotify pour voir quand le fichier est supprimé.

Solution 3 : ftrace
Une autre solution consiste à utiliser ftrace :

trace-cmd record -e \*unlink\*

Attendez que le fichier soit supprimé, appuyez sur CTRL + C pour arrêter trace-cmd record ..., puis exécutez:

trace-cmd report

Solution 4 :
installez bpftrace bpftrace, puis exécutez:

bpftrace -e 'tracepoint:syscalls:sys_enter_unlink* { printf("%s %s\n", comm, str(args->pathname)); }'

en plus de la réponse de micea, vous pouvez chatter + i les fichiers en tant que root et voir si quelque chose enregistre une erreur lorsque vous essayez de les supprimer.

Êtes-vous absolument sûr que l'utilisateur lui-même ne les supprime pas (accidentellement)?

J'ai eu quelques utilisateurs (Windows) désemparés avec le même problème. Il s'est avéré qu'ils supprimaient ces fichiers eux-mêmes chaque fois qu'ils visitaient leur répertoire personnel avec un client ftp. Ils ont remarqué les fichiers .xxxx (le client ftp ne les a pas cachés) et ont supprimé le "fouillis".

Il ne m'est jamais venu à l'esprit qu'ils l'ont fait pour eux-mêmes jusqu'à ce que l'un d'eux se plaigne des fichiers réapparaissant spontanément qu'il avait supprimés plusieurs jours auparavant.

Nous utilisons des scripts de déconnexion bash (~ / .bash_logout) pour nettoyer certains fichiers lors de la déconnexion - vous pouvez vérifier si vous avez cette configuration, peut-être avec un glob à gros doigts.

More ressemble à un intrus, qui fait un find / home / user -name filename -exec rm -f {} \; après tout son se faufiler :). Juste deviner, car vous avez mentionné que les fichiers de sauvegarde sont également supprimés.

Pour éviter de perdre les fichiers et leur contenu, vous pouvez configurer libtrash via LD_PRELOAD. En utilisant libtrash, vous pouvez faire un certain nombre de choses, mais celles qui pourraient vous intéresser sont

INTERCEPT_UNLINK
INTERCEPT_RENAME
INTERCEPT_FOPEN
INTERCEPT_OPEN

Un bon article sur libtrash peut être trouvé ici

Une autre chose que vous mentionnez, c'est que vous avez tronqué des fichiers à la racine et qu'ils ont toujours été supprimés. C'est parce que / home / username appartient à username; et si dir a dit le mod 755; puis tout fichier ou répertoire dans ce répertoire appartenant à n'importe qui peut être supprimé par l'utilisateur; même s'il s'agit d'un fichier racine ou d'un répertoire. C'est essentiellement dû au fait que supprimer le fichier dans le répertoire signifie changer le contenu du répertoire et l'utilisateur a 7 (dans 755) de ce répertoire afin qu'il puisse faire ce qu'il veut.

Il existe des moyens de bloquer cela, comme d'autres personnes l'ont déjà suggéré via chattr sur les systèmes de fichiers ext pour définir les fichiers comme immuables (+ i). Ensuite, il faudrait désactiver l'indicateur immuable avant d'apporter des modifications au fichier / dir qui a l'indicateur + i. Le drapeau / chattr immuable ne peut être utilisé que par root.