"cd" dans / sys / kernel / debug / tracing provoque un changement d'autorisation
J'ai fait face à un problème vraiment étrange aujourd'hui, et je suis totalement impuissant à ce sujet.
Certains des serveurs que je gère sont surveillés avec Nagios. Récemment, j'ai vu une sonde d'utilisation de disque échouer avec cette erreur:
DISK CRITICAL -/sys/kernel/debug/tracing n'est pas accessible: autorisation refusée
Je voulais enquêter et mon premier essai a été de vérifier les autorisations de ce répertoire et de les comparer avec un autre serveur (qui fonctionne bien). Voici les commandes que j'ai exécutées sur le serveur de travail et vous verrez que dès que je cd dans le répertoire, ses permissions sont modifiées:
# Here we've got 555 for /sys/kernel/debug/tracing
root@vps690079:/home/admin# cd /sys/kernel/debug
root@vps690079:/sys/kernel/debug# ll
total 0
drwx------ 30 root root 0 Jul 19 13:13 ./
drwxr-xr-x 13 root root 0 Jul 19 13:13 ../
…
dr-xr-xr-x 3 root root 0 Jul 19 13:13 tracing/
drwxr-xr-x 6 root root 0 Jul 19 13:13 usb/
drwxr-xr-x 2 root root 0 Jul 19 13:13 virtio-ports/
-r--r--r-- 1 root root 0 Jul 19 13:13 wakeup_sources
drwxr-xr-x 2 root root 0 Jul 19 13:13 x86/
drwxr-xr-x 2 root root 0 Jul 19 13:13 zswap/
# I cd into the folder, and it (./) becomes 700!!
root@vps690079:/sys/kernel/debug# cd tracing/
root@vps690079:/sys/kernel/debug/tracing# ll
total 0
drwx------ 8 root root 0 Jul 19 13:13 ./
drwx------ 30 root root 0 Jul 19 13:13 ../
-r--r--r-- 1 root root 0 Jul 19 13:13 available_events
-r--r--r-- 1 root root 0 Jul 19 13:13 available_filter_functions
-r--r--r-- 1 root root 0 Jul 19 13:13 available_tracers
…
# Next commands are just a dumb test to double-check what I'm seeing
root@vps690079:/sys/kernel/debug/tracing# cd ..
root@vps690079:/sys/kernel/debug# ll
total 0
drwx------ 30 root root 0 Jul 19 13:13 ./
drwxr-xr-x 13 root root 0 Sep 27 10:57 ../
…
drwx------ 8 root root 0 Jul 19 13:13 tracing/
drwxr-xr-x 6 root root 0 Jul 19 13:13 usb/
drwxr-xr-x 2 root root 0 Jul 19 13:13 virtio-ports/
-r--r--r-- 1 root root 0 Jul 19 13:13 wakeup_sources
drwxr-xr-x 2 root root 0 Jul 19 13:13 x86/
drwxr-xr-x 2 root root 0 Jul 19 13:13 zswap/
Avez-vous une idée de ce qui pourrait provoquer ce comportement?
Note latérale, l'utilisation de chmod pour rétablir les autorisations ne semble pas réparer la sonde.
/ sys
/sys est sysfs, une vue entièrement virtuelle des structures du noyau en mémoire qui reflète la configuration actuelle du noyau du système et du matériel, et ne consomme aucun espace disque réel. Les nouveaux fichiers et répertoires ne peuvent pas y être écrits normalement.
L'application de la surveillance de l'espace disque ne produit pas d'informations utiles et représente un gaspillage d'efforts. Il peut contenir des points de montage pour d'autres systèmes de fichiers virtuels basés sur la RAM, y compris ...
/ sys/kernel/debug
/sys/kernel/debug est le point de montage standard pour debugfs, qui est un système de fichiers virtuel facultatif pour diverses fonctionnalités de débogage et de traçage du noyau.
Parce qu'il s'agit de fonctionnalités de débogage, il est censé être inutile pour une utilisation en production (bien que vous puissiez choisir d'utiliser certaines des fonctionnalités pour des statistiques système améliorées ou similaires).
Étant donné que l'utilisation des fonctionnalités offertes par debugfs nécessitera dans la plupart des cas d'être root de toute façon, et que son objectif principal est d'être un moyen simple pour les développeurs du noyau de fournir des informations de débogage, cela peut être un peu " rugueux sur les bords ".
Lorsque le noyau a été chargé, la routine d'initialisation du sous-système de suivi du noyau a enregistré /sys/kernel/debug/tracing en tant que point d'accès debugfs pour lui-même, différant toute initialisation supplémentaire jusqu'à ce qu'il soit réellement accédé pour la première fois (en minimisant l'utilisation des ressources du sous-système de suivi au cas où il s'avérerait que ce n'est pas nécessaire). Lorsque vous cd 'dans le répertoire, cette initialisation différée a été déclenchée et le sous-système de suivi s'est préparé pour l'utilisation. En effet, l'original /sys/kernel/debug/tracing était initialement un mirage sans substance, et il n'est devenu "réel" que lorsque (et parce que) vous y avez accédé avec votre commande cd.
debugfs n'utilise aucun espace disque réel: toutes les informations qu'il contient disparaîtront à l'arrêt du noyau.
/ sys/fs/cgroup
/sys/fs/cgroup est un système de fichiers basé sur RAM de type tmpfs, utilisé pour regrouper divers processus en cours d'exécution en groupes de contrôle . Il n'utilise pas du tout d'espace disque réel. Mais si ce système de fichiers est presque plein pour une raison quelconque, cela pourrait être plus grave que de manquer d'espace disque: cela pourrait signifier que
a) vous manquez de RAM libre,
b) un processus appartenant à root écrit des ordures dans /sys/fs/cgroup, ou
c) quelque chose provoque la création d'un nombre vraiment absurde de groupes de contrôle, peut-être dans le style d'une "bombe fourchette" classique mais avec des services basés sur systemd ou similaires.
Conclusion
ne sonde d'utilisation du disque doit avoir /sys exclus car rien sous /sys est stocké sur n'importe quel disque.
Si vous devez surveiller /sys/fs/cgroup, vous devez lui fournir une sonde dédiée qui fournira des alertes plus significatives qu'une sonde d'espace disque générique.