Empêcher le renommage de fichier

Système d'exploitation Linux
1

Bonjour,

Je suis en train de mettre en place une tâche planifiée qui permet de bloquer les fichiers et les dossiers créés dans un répertoire dans un temps compris entre X minutes et 2X minutes.

Ça met juste les droits en 440 pour les fichiers, et en 550 pour les répertoires.

Mais oh surprise, je me suis rendu compte que si ça empêchait bien l’édition, ça n’empêche pas le renommage !
Aussi étonnant que ça puisse paraitre, le fichier “toto.txt” qui est bien en 440, peut être renommé par un simple mv (et donc déplacé par la même occasion).

Quelqu’un peut m’expliquer comment c’est possible ? Et par la même occasion comment empêcher ça ? Sinon mon système ne sert à rien…

Merci.
Edité le 09/09/2008 à 15:28

2

C’est un droit du répertoire sous jacent :stuck_out_tongue:

3

Sous-jacent ? :confused:
Tu veux dire du dessus au contraire :slight_smile:

Ben non…
J’ai bien un répertoire :

dr-xr-x---  test2

Et à l’intérieur, un fichier :

-r--r-----  test4.txt

Et :

# mv test4.txt test5.txt
# ls -l
-r--r----- test5.txt

Edité le 09/09/2008 à 15:52

4

:confused:

mkdir test cd test touch a chmod uog-xw a mv a b mv b a cd .. chmod uog-w test cd test mv a b mv: ne peut déplacer `a' vers `b': Permission non accordée
5

le fait d’être ne root ne te donne pas le droit de passer au dessus de ces droits ? [edit= heuu c’est pas forcément clair ! :ane: ]
sinon la solution ne viendrait-elle pas du “bit immuable” ?

www.lea-linux.org…
Edité le 09/09/2008 à 16:10

6

Bon, je zappe pour l’instant sur le problème, car je me suis rendu compte d’une “faille” dans mon système…

Je l’explique.

Mon but est de créer un dépôt d’archive.

Chacun peut créer des répertoires et y stocker des fichiers.

Mais à intervalle régulier, les fichiers doivent être bloqués pour ne pas pouvoir être modifié… La structure arborescente peut aussi être créée, mais elle doit aussi se figer. J’entrevois plusieurs soucis :

  • Pour créer un répertoire ou un fichier, il faut un droit en w sur le répertoire parent
  • Quand un répertoire est en w, on peut renommer ou déplacer les fichiers qui sont dessous -> Incompatibilité
  • Quand un fichier est en lecture seule, ça n’empêche pas de le renommer, ou de le déplacer, si le répertoire est en w -> Autre incompatibilité…

Quelqu’un saurait comment faire un tel système qui fige l’existant, tout en permettant d’ajouter de nouveaux fichiers ?

7

avec des ACL, mais ce n’est pas fameux.

Le plus fiable est de déporter la gestion par rapport au support. Interface contrôlée par un programme qui accède à un démon (même en local, mais avec un autre utilisateur) et seul le démon a les droits rw.

8

Ca, ca sent un besoin d’archivage legal non ?
On n’est en train de se poser la meme question dans ma boite… :ane:
Mais nous, au lieu, de chipoter avec des serveurs maison, on va probablement partir sur une solution centera ou un archivage du meme genre deporte chez un presta…

Quoiqu’il en soit, ce genre de truc est pas facile des qu’on commence a gratter le probleme.
Rq : tu pourrais eventuellement etudier le principe des bandes worm pour figer tes fichiers.

9

Ouais mais nan, c’est pas possible… Ça doit être simple à développer (LE perl, c’est bien), à installer (tâche cron et hop !) et à utiliser (smb obligatoire).

Non pas du tout… C’est une amélioration de notre gestion “propre” de projets…

C’est pas le même budget non plus :confused:

Pas de budget non plus pour un système à bande… :confused:

10

Essayez subversion des fois … ça risque de simplifier pas mal ce genre de problème, et les outils sont prêts …

11

On utilise déjà subversion. C’est justement pour ça qu’on veut changer… C’est trop contraignant, et ça ne résoud pas le problème (une fois versionné, rien n’empêche de modifier, et de commiter à nouveau)…

12

tu graves a la volee sur un CD ? :paf:

13

J’en reste à mon idée de démon, qui est “assez peu” coûteuse :frowning:

PS : c’est une manie là ou tout le monde fait le même truc en même temps ?

14

Bah écoute, je suis toujours preneur d’idées, mais je vois pas comment ton idée peut être mise en place en moins de 8 heures, dans des conditions de sécurité minimum (tests éprouvés, réflexion sur les effets de bord, etc.)

:etonne2:

15

Non c’est clair, pas en 8h. Le double, minimum.

(je code un truc dans ce genre … )

Tu ouvre un pipe nommé, tu as un démon qui le lis le pipe tu écris un second programme qui prend en argument le fichier, et qui écrit dans le tube

store:path/to/file::

le démon copie et efface le fichier, c’est fini.
avec les tests, plus de 8h, mais pas tant que ça.

(Après pour la récupération des fichiers tes utilisateurs peuvent avoir les droits de lecture ...
16

toll : C’est parce que perl c’est nul pour ce genre de truc!

Le demon en python … la commande suit.

#!/usr/bin/python
      
import os
from shutil import copyfile


FIFO = "tmp/fifo1"
DESTINATION = "/storage/path/"

os.mkfifo(FIFO)
      
fifo = open(FIFO, 'r+')

while True:

        cmd = fifo.read()

        commande = cmd.split(":")
        if len(commande) != 2:
                continue
        if commande[0] == "STORE":
                filename = os.path.split(commande[1])[1]
                copyfile(commande[1], os.path.join(DESTINATION, filename)
``` import sys from os import open

def main():
fifo = open(FIFO, ‘w’)

if len(sys.argv) != 2:
    usage(1)


fifo.write("STORE:"+sys.argv[1])
fifo.close()

if name == ‘main’:
main()



La commande doit ressembler à ça. (je n'ai rien testé du tout. !)
Edité le 09/09/2008 à 18:09
17

python, c’est pas mieux que perl hein, c’est purement subjectif… Perso je trouve ça ignoble…
Perl, tu peux faire des choses crades, mais avec de bonnes pratiques, tu peux faire du propre.
Je trouve le Python crade par définition…

Enfin, les goûts et les couleurs…

Bref, ton système implique d’utiliser un programme pour déposer le fichier non ? C’est super pas pratique… Quid de la portabilité et de l’accès réseau ?

De plus, le système de copie n’est pas exploitable.
Pour la simple et bonne raison que si tu déplace les fichiers, et donc l’arborescence, ça t’oblige à refaire toute l’arborescence à chaque fois que tu veux ajouter un fichier à un répertoire.
Ou sinon, tu conserve l’arborescence, mais vide… C’est effectivement envisageable, et j’y pense tout juste…
Le défaut, c’est que les personnes ne vont pas forcément comprendre pourquoi lorsqu’ils mettent une mise à jour d’un fichier, cette mise à jour n’est pas reportée (on ne peut pas modifier un fichier existant, donc si le fichier destination existe, on supprime simplement le fichier source).

J’étudie la possibilité d’une config smb. De mémoire, il existe un système de “create only”…

Bon, la solution, c'était d'utiliser les option create mask directory mask de SMB, mais le problème revient exactement au même :(
18

oula ! y’a du troll dans l’air :ane:

19

Non, c’est mon avis, et j’ai découvert récemment que je suis loin d’être le seul à l’avoir :wink:
Je n’ai rien contre ceux qui font du Python, mais celui qui m’en fera faire n’est pas né :stuck_out_tongue:
Quant à dire qu’il est génial car facile à lire (on entend ça sur Ruby aussi), c’est subjectif, et je ne suis pas d’accord…

Bon, ceci dit, je serai plus enclin à faure du Python que du Ruby hein…
Je préfèrerai faire du Cobol plutôt que du Ruby, et avec un petit travail sur moi-même, je pourrais faire du Python.

Pour un bon salaire… Un trèèèèèèèèèèèèès bon salaire :slight_smile:

Mais qu’est-ce que je trouve ça crade… Le coût de la syntaxe faite par des tabulations, je trouve ça d’une incertitude totale quant au résultat…
Edité le 09/09/2008 à 18:50

20

hum a ma connaissance, tu resoudras pas ton probleme avec les droits…
Je connais pas un seul OS disposant d’ACL suffisamment fines pour faire ce que tu veux. Meme windows qui disposes d’ACL tres fines ne permet pas ce genre de truc (pour une fois que je dis du bien de windows, faut le souligner)