Journal LoggedFS v0.4

Posté par  .
Étiquettes : aucune
0
23
jan.
2007
LoggedFS est un outil basé sur Fuse qui permet de voir les différentes opérations sur les fichiers dans un répertoire donné.

Les opérations sont loggées soit dans syslog soit dans un fichier à part. Il est possible de lancer le processus en tant que daemon pour surveiller toutes les opérations dans un répertoire donné.

Au niveau de l'implémentation il s'agit en fait d'un fs basé sur fuse qui va se contenter de logger les opérations avant de laisser le "vrai" système de fichiers les exécuter.

Un fichier de configuration permet de filtrer les opérations loggées par type d'opération, nom de fichiers, nom d'utilisateur et enfin code de retour.

La version 0.4 est sortie aujourd'hui apporte des corrections de bugs, le support de fuse v2.6 et le support complet des inodes.

Page du projet : http://loggedfs.sourceforge.net/

  • # Bonne idee

    Posté par  . Évalué à 5.

    Interessant, ca peut etre utile :)

    • [^] # Re: Bonne idee

      Posté par  . Évalué à 2.

      Interessant, ca peut etre utile

      Comme je suis bête, je ne vois pas très bien à quoi.
      Pourrais-tu développer s'il te plait ?

      • [^] # Re: Bonne idee

        Posté par  . Évalué à 1.

        Tracer ce que fait un programme avec ses fichiers sans lancer ptrace, ni auditer le source, par exemple.

        • [^] # Re: Bonne idee

          Posté par  (site web personnel) . Évalué à 1.

          Oui enfin on a la meme chose avec inotifywatch.

          • [^] # Re: Bonne idee

            Posté par  . Évalué à 3.

            Je ne pense pas que tu puisses avoir autre chose que des statistiques avec inotifywatch. LoggedFS t'indique qui fait quoi sur ton FS en temps réel. Tu ne peux pas non plus filtrer par utilisateur. Tu n'as pas la durée des opérations de lecture/écriture.

            Je ne pense pas (mais ça faudrait vérifier) que tu puisses avoir le code retour des opérations.

            Quelqu'un a par exemple utilisé loggedfs pour comprendre pourquoi ses paramèter kde étaient perdus : http://shlomif.livejournal.com/22219.html , et il a pu savoir quel processus écrasait son fichier de configuration.

            inotifywatch et loggedfs n'ont donc pas la même utilité. Par contre il est tout à fait possible d'écrire un truc qui ferait à peu près le même boulot que loggedfs, mais basé sur inotify (et ça serait sûrement beaucoup plus rapide). Quand j'ai eu besoin d'un outil qui faisait ce travail, je n'avais pas besoin des performances, inotify n'était pas encore dans le kernel et fuse était déjà utilisable.

      • [^] # Re: Bonne idee

        Posté par  . Évalué à 2.

        Dans un contexte professionnel ou associatif d'un serveur de fichiers partagé savoir qui est le {#~[[{#|#~! qui a modifié/supprimé/déplacé le fichier hyper important qu'il n'était pas sensé toucher.

        BeOS le faisait il y a 20 ans !

        • [^] # Re: Bonne idee

          Posté par  . Évalué à 4.

          Dans un contexte professionnel ou associatif d'un serveur de fichiers partagé savoir qui est le {#~[[{#|#~! qui a modifié/supprimé/déplacé le fichier hyper important qu'il n'était pas sensé toucher.

          D'un poin de vue professionnel , (les assoc c'est autre chose), si quelqu'un peut faire quelquechose , qui peut géner les autres, et qu'il a pas le droit de le faire c'est que la sécu est mal pensée.
          Aucun systeme de logs ou autre empechera cet état de fait.

          • [^] # Re: Bonne idee

            Posté par  . Évalué à 3.

            Exactement ! Si l'on doit en arriver la c'est que la gestion globale de sécu est vraiment mal fichue.

            Je dirais même plus qu'une utilisation intensive de cet outil de diagnostique doit avoir un coût de performance non négligeable (sans parler des logs qui explosent).
            Bref, tout cela me rappelle curieusement une histoire de marteau et de clous...

            À part cela c'est un projet très intéressant qui me pourrait bien me servir un jour. Merci Rémi de nous en parler :-)

          • [^] # Re: Bonne idee

            Posté par  . Évalué à 5.

            D'un poin de vue professionnel , (les assoc c'est autre chose), si quelqu'un peut faire quelquechose , qui peut géner les autres, et qu'il a pas le droit de le faire c'est que la sécu est mal pensée.

            Dans un contexte professionnel, la sécu est en general mal pensée.

            • [^] # Re: Bonne idee

              Posté par  . Évalué à 2.

              Je suis d'accord : la sécu est souvent mal pensée.

              Il n'y a pas forcément d'administrateur local qui gère les droits mais seulement une lointaine entité qui met trèèès longtemps à réagir.

              On a lors le choix entre laisser tout le monde toucher à tout et attendre des semaines pour avoir enfin un accès en lecture à un dossier partagé (c'est du vécu).

              BeOS le faisait il y a 20 ans !

  • # Je suis sûr de n'être pas le seul à y avoir pensé...

    Posté par  . Évalué à 3.

    Et peut-on forcer LoggedFS à tracer les opérations dans un fichier qui se trouve dans l'arborescence du FS qu'il surveille ? :-)

    Suis déjà dehors...

  • # Fuse pour ça ?

    Posté par  . Évalué à 1.

    Pourquoi ne pas utiliser [sp]trace tout simplement ?

    Au dela de cette interrogation, question "réactivité" du système, ça donne quoi ?

    • [^] # Re: Fuse pour ça ?

      Posté par  . Évalué à 2.

      Par ce que tu as pas forcement envie ou la possibilité de lancer tous tes processus avec [sp]trace, et par ce que tu connais pas forcement a l'avance le ou les processus qui vont tenter d'acceder à ces fichiers.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.