Mon problème est de savoir, dans la mesure du possible, quel user à supprimer mon fichier avec quelle commande ou script.
Est-ce que si l'effacement est effectué via un "echo '' > fichier" ça doit aussi etre comptabilisé?
Guytou
Est-ce que si l'effacement est effectué via un "echo '' > fichier" ça doit aussi etre comptabilisé?
Bonjour à Tous, Bonjour Mihamina
OUI, j'aimerai dans la mesure du possible que tout type d'effacement soit comptabilisé. Le but est de savoir qui a supprimé et avec quelle commande ou script.
Merci de votre participation.
GUYTOU
"Rakotomandimby (R12y) Mihamina" a écrit dans le message de news: eqtfs3$2k0g$
Guytou wrote:
Mon problème est de savoir, dans la mesure du possible, quel user à supprimer mon fichier avec quelle commande ou script.
Est-ce que si l'effacement est effectué via un "echo '' > fichier" ça doit aussi etre comptabilisé?
Est-ce que si l'effacement est effectué via un "echo '' > fichier" ça doit
aussi etre comptabilisé?
Bonjour à Tous,
Bonjour Mihamina
OUI, j'aimerai dans la mesure du possible que tout type d'effacement soit
comptabilisé.
Le but est de savoir qui a supprimé et avec quelle commande ou script.
Merci de votre participation.
GUYTOU
"Rakotomandimby (R12y) Mihamina"
<mihamina.rakotomandimby@etu.univ-orleans.fr> a écrit dans le message de
news: eqtfs3$2k0g$4@cabale.usenet-fr.net...
Guytou wrote:
Mon problème est de savoir, dans la mesure du possible, quel user à
supprimer mon fichier avec quelle commande ou script.
Est-ce que si l'effacement est effectué via un "echo '' > fichier" ça doit
aussi etre comptabilisé?
Est-ce que si l'effacement est effectué via un "echo '' > fichier" ça doit aussi etre comptabilisé?
Bonjour à Tous, Bonjour Mihamina
OUI, j'aimerai dans la mesure du possible que tout type d'effacement soit comptabilisé. Le but est de savoir qui a supprimé et avec quelle commande ou script.
Merci de votre participation.
GUYTOU
"Rakotomandimby (R12y) Mihamina" a écrit dans le message de news: eqtfs3$2k0g$
Guytou wrote:
Mon problème est de savoir, dans la mesure du possible, quel user à supprimer mon fichier avec quelle commande ou script.
Est-ce que si l'effacement est effectué via un "echo '' > fichier" ça doit aussi etre comptabilisé?
Pascal Bourguignon
"Guytou" writes:
OUI, j'aimerai dans la mesure du possible que tout type d'effacement soit comptabilisé. Le but est de savoir qui a supprimé et avec quelle commande ou script.
Il y a le "process accounting" qui "comptabilise" toutes les commandes exécutées sur un système unix, mais en général, ça ne garde pas trace des arguments, alors on ne saurait pas quel argument a été donné à rm(1) et de toutes façons, on peut supprimer des fichiers avec à peu près n'importe quel programme...
Donc, le plus fiable serait de "patcher" le noyau. Sur Linux, il est possible qu'il y ait une version du noyau ou au moins un file system qui garde trace (audit) de ce genre d'information. Voir peut être, SELinux http://www.nsa.gov/selinux/ ou googled sur Linux audit trail il y a peut être quelque chose déjà fait dans ce domaine.
HEALTH WARNING: Care should be taken when lifting this product, since its mass, and thus its weight, is dependent on its velocity relative to the user.
"Guytou" <mapasa@free.fr> writes:
OUI, j'aimerai dans la mesure du possible que tout type d'effacement soit
comptabilisé.
Le but est de savoir qui a supprimé et avec quelle commande ou script.
Il y a le "process accounting" qui "comptabilise" toutes les commandes
exécutées sur un système unix, mais en général, ça ne garde pas trace
des arguments, alors on ne saurait pas quel argument a été donné à
rm(1) et de toutes façons, on peut supprimer des fichiers avec à peu
près n'importe quel programme...
Donc, le plus fiable serait de "patcher" le noyau. Sur Linux, il est
possible qu'il y ait une version du noyau ou au moins un file system
qui garde trace (audit) de ce genre d'information. Voir peut être,
SELinux http://www.nsa.gov/selinux/ ou googled sur Linux audit trail
il y a peut être quelque chose déjà fait dans ce domaine.
HEALTH WARNING: Care should be taken when lifting this product,
since its mass, and thus its weight, is dependent on its velocity
relative to the user.
OUI, j'aimerai dans la mesure du possible que tout type d'effacement soit comptabilisé. Le but est de savoir qui a supprimé et avec quelle commande ou script.
Il y a le "process accounting" qui "comptabilise" toutes les commandes exécutées sur un système unix, mais en général, ça ne garde pas trace des arguments, alors on ne saurait pas quel argument a été donné à rm(1) et de toutes façons, on peut supprimer des fichiers avec à peu près n'importe quel programme...
Donc, le plus fiable serait de "patcher" le noyau. Sur Linux, il est possible qu'il y ait une version du noyau ou au moins un file system qui garde trace (audit) de ce genre d'information. Voir peut être, SELinux http://www.nsa.gov/selinux/ ou googled sur Linux audit trail il y a peut être quelque chose déjà fait dans ce domaine.
HEALTH WARNING: Care should be taken when lifting this product, since its mass, and thus its weight, is dependent on its velocity relative to the user.
Alain Ketterlin
"Guytou" writes:
Comment surveiller efficacement un fichier présent dans un répertoire.
1/ Pour être informé dés sa suppression 3/ Pour savoir quand il a été supprimé
Si c'est sous Linux, il y a inotify(7).
2/ Pour connaitre quel user l'a supprimé en utilisant quelle commande UNIX ou script
Ca, ça me semble sans espoir...
# Je crée la liste des process et user présent sur le serveur au moment de la suppression de mon fichier ps -edf >> supprime.txt
:-) J'espère que tu ne comptes pas trop là-dessus. Sinon, tu peux regarder du coté de utmp et wtmp.
-- Alain.
"Guytou" <mapasa@free.fr> writes:
Comment surveiller efficacement un fichier présent dans un répertoire.
1/ Pour être informé dés sa suppression
3/ Pour savoir quand il a été supprimé
Si c'est sous Linux, il y a inotify(7).
2/ Pour connaitre quel user l'a supprimé en utilisant quelle
commande UNIX ou script
Ca, ça me semble sans espoir...
# Je crée la liste des process et user présent sur le serveur au
moment de la suppression de mon fichier
ps -edf >> supprime.txt
:-) J'espère que tu ne comptes pas trop là-dessus. Sinon, tu peux
regarder du coté de utmp et wtmp.
Comment surveiller efficacement un fichier présent dans un répertoire.
1/ Pour être informé dés sa suppression 3/ Pour savoir quand il a été supprimé
Si c'est sous Linux, il y a inotify(7).
2/ Pour connaitre quel user l'a supprimé en utilisant quelle commande UNIX ou script
Ca, ça me semble sans espoir...
# Je crée la liste des process et user présent sur le serveur au moment de la suppression de mon fichier ps -edf >> supprime.txt
:-) J'espère que tu ne comptes pas trop là-dessus. Sinon, tu peux regarder du coté de utmp et wtmp.
-- Alain.
Marc Mezzarobba
Donc, le plus fiable serait de "patcher" le noyau. Sur Linux, il est possible qu'il y ait une version du noyau ou au moins un file system qui garde trace (audit) de ce genre d'information.
Il doit même être possible d'écrire un système de fichiers fuse qui rajoute ça par-dessus n'importe quel système de fichiers normal, non ?
-- Marc Mezzarobba
Donc, le plus fiable serait de "patcher" le noyau. Sur Linux, il est
possible qu'il y ait une version du noyau ou au moins un file system
qui garde trace (audit) de ce genre d'information.
Il doit même être possible d'écrire un système de fichiers fuse qui rajoute
ça par-dessus n'importe quel système de fichiers normal, non ?
Donc, le plus fiable serait de "patcher" le noyau. Sur Linux, il est possible qu'il y ait une version du noyau ou au moins un file system qui garde trace (audit) de ce genre d'information.
Il doit même être possible d'écrire un système de fichiers fuse qui rajoute ça par-dessus n'importe quel système de fichiers normal, non ?
-- Marc Mezzarobba
Vincent Lefevre
Dans l'article <eqtbm6$m55$, LinuxKiller écrit:
Si le user lambda peut effacer les fichiers du user alpha, c'est grave !
Je ne vois pas le problème. C'est bien utile sur des répertoires partagés (genre site web maintenu à plusieurs). Ça évite, quand alpha n'est pas là, de se retrouver bloqué avec un truc à modifier d'urgence (et ça évite de créer un utilisateur spécialisé pour cela).
Si un user basique a supprimé ton noyau, c'est très grave !!!
Dans l'article <eqtbm6$m55$1@gyptis.org>,
LinuxKiller <linuxfucker@linuxkiller.labas.org> écrit:
Si le user lambda peut effacer les fichiers du user alpha, c'est grave !
Je ne vois pas le problème. C'est bien utile sur des répertoires
partagés (genre site web maintenu à plusieurs). Ça évite, quand
alpha n'est pas là, de se retrouver bloqué avec un truc à modifier
d'urgence (et ça évite de créer un utilisateur spécialisé pour
cela).
Si un user basique a supprimé ton noyau, c'est très grave !!!
Si le user lambda peut effacer les fichiers du user alpha, c'est grave !
Je ne vois pas le problème. C'est bien utile sur des répertoires partagés (genre site web maintenu à plusieurs). Ça évite, quand alpha n'est pas là, de se retrouver bloqué avec un truc à modifier d'urgence (et ça évite de créer un utilisateur spécialisé pour cela).
Si un user basique a supprimé ton noyau, c'est très grave !!!
Je ne vois pas le problème. C'est bien utile sur des répertoires partagés (genre site web maintenu à plusieurs). Ça évite, quand alpha n'est pas là, de se retrouver bloqué avec un truc à modifier d'urgence (et ça évite de créer un utilisateur spécialisé pour cela).
Oui, mais dans ce cas de figure: - On ne travaille pas directement sur la machine de production (on réduit déjà un peu la gravité des erreurs) - On utilise l'un des outils de gestion de travail collaboratif qui existent (SVN, CVS,... pour les développeurs ou autre CMS pour les autres, avec ce qu'il y a comme outils, il y en a pour tous les profils)
Vincent Lefevre wrote:
Je ne vois pas le problème. C'est bien utile sur des répertoires
partagés (genre site web maintenu à plusieurs). Ça évite, quand
alpha n'est pas là, de se retrouver bloqué avec un truc à modifier
d'urgence (et ça évite de créer un utilisateur spécialisé pour
cela).
Oui, mais dans ce cas de figure:
- On ne travaille pas directement sur la machine de production (on réduit
déjà un peu la gravité des erreurs)
- On utilise l'un des outils de gestion de travail collaboratif qui existent
(SVN, CVS,... pour les développeurs ou autre CMS pour les autres, avec ce
qu'il y a comme outils, il y en a pour tous les profils)
Je ne vois pas le problème. C'est bien utile sur des répertoires partagés (genre site web maintenu à plusieurs). Ça évite, quand alpha n'est pas là, de se retrouver bloqué avec un truc à modifier d'urgence (et ça évite de créer un utilisateur spécialisé pour cela).
Oui, mais dans ce cas de figure: - On ne travaille pas directement sur la machine de production (on réduit déjà un peu la gravité des erreurs) - On utilise l'un des outils de gestion de travail collaboratif qui existent (SVN, CVS,... pour les développeurs ou autre CMS pour les autres, avec ce qu'il y a comme outils, il y en a pour tous les profils)
Pascal Bourguignon
Marc Mezzarobba <mm$ writes:
Donc, le plus fiable serait de "patcher" le noyau. Sur Linux, il est possible qu'il y ait une version du noyau ou au moins un file system qui garde trace (audit) de ce genre d'information.
Il doit même être possible d'écrire un système de fichiers fuse qui rajoute ça par-dessus n'importe quel système de fichiers normal, non ?
"Debugging? Klingons do not debug! Our software does not coddle the weak."
Marc Mezzarobba <mm$usenet@mezzarobba.net> writes:
Donc, le plus fiable serait de "patcher" le noyau. Sur Linux, il est
possible qu'il y ait une version du noyau ou au moins un file system
qui garde trace (audit) de ce genre d'information.
Il doit même être possible d'écrire un système de fichiers fuse qui rajoute
ça par-dessus n'importe quel système de fichiers normal, non ?
Donc, le plus fiable serait de "patcher" le noyau. Sur Linux, il est possible qu'il y ait une version du noyau ou au moins un file system qui garde trace (audit) de ce genre d'information.
Il doit même être possible d'écrire un système de fichiers fuse qui rajoute ça par-dessus n'importe quel système de fichiers normal, non ?
"Debugging? Klingons do not debug! Our software does not coddle the weak."
Vincent Lefevre
Dans l'article <eqv0jg$291n$, "Rakotomandimby (R12y) Mihamina" écrit:
- On ne travaille pas directement sur la machine de production (on réduit déjà un peu la gravité des erreurs)
Ben si, puisque c'est pour mettre à jour le site.
- On utilise l'un des outils de gestion de travail collaboratif qui existent (SVN, CVS,... pour les développeurs ou autre CMS pour les autres, avec ce qu'il y a comme outils, il y en a pour tous les profils)
Subversion, etc., c'est plutôt fait pour les sources, mais pas pour les fichiers eux-mêmes qui seront sur le serveur.
Dans l'article <eqv0jg$291n$1@cabale.usenet-fr.net>,
"Rakotomandimby (R12y) Mihamina" <mihamina.rakotomandimby@etu.univ-orleans.fr> écrit:
- On ne travaille pas directement sur la machine de production (on réduit
déjà un peu la gravité des erreurs)
Ben si, puisque c'est pour mettre à jour le site.
- On utilise l'un des outils de gestion de travail collaboratif qui existent
(SVN, CVS,... pour les développeurs ou autre CMS pour les autres, avec ce
qu'il y a comme outils, il y en a pour tous les profils)
Subversion, etc., c'est plutôt fait pour les sources, mais pas pour
les fichiers eux-mêmes qui seront sur le serveur.
Dans l'article <eqv0jg$291n$, "Rakotomandimby (R12y) Mihamina" écrit:
- On ne travaille pas directement sur la machine de production (on réduit déjà un peu la gravité des erreurs)
Ben si, puisque c'est pour mettre à jour le site.
- On utilise l'un des outils de gestion de travail collaboratif qui existent (SVN, CVS,... pour les développeurs ou autre CMS pour les autres, avec ce qu'il y a comme outils, il y en a pour tous les profils)
Subversion, etc., c'est plutôt fait pour les sources, mais pas pour les fichiers eux-mêmes qui seront sur le serveur.