Comment verrouiller un fichier contre la suppression tout en le rendant accessible en écriture?

33

Je souhaite verrouiller un fichier contre la suppression tout en restant accessible en écriture. Comment puis-je faire cela?

Le fichier en question est un volume TrueCrypt en tant que fichier sur un partage réseau SMB NAS, je ne souhaite donc pas le supprimer accidentellement.

linux windows filesystems

— therobyouknow
source

1

Ce n'est pas possible. Écrire des zéros revient à le supprimer.

— soandos

@soandos - Je ne suis pas d'accord, j'ai peur. Parce que l'écriture de zéros signifie toujours que le fichier existe, mais qu'il est plein de zéros. En effet, il existe des commandes Linux pour créer un fichier «fragmenté» plein de zéros.

— therobyouknow

34

Pour les fenêtres:

Refuser l'autorisation "Supprimer" sur le fichier.
Supprimer ou refuser l'autorisation "Supprimer les éléments enfants" sur le répertoire parent.

Pour Unix (y compris OS X):

Supprimer l'autorisation "Write" sur le répertoire parent.

Notez que cela empêchera seulement le fichier d'être supprimé (supprimé), mais ne fera rien contre la troncature accidentelle ou l'écrasement avec garbage. Si un fichier est accessible en écriture, vous pouvez tout écrire, point à la ligne.

En outre, les autorisations de fichiers sont pratiquement impossibles à traduire entre les systèmes d'exploitation. Si le NAS exécute Linux et que vous essayez de définir des autorisations à partir de Windows, le résultat final peut être différent de celui attendu.

— Grawity
source

La meilleure réponse que je vais obtenir je pense. +1 et merci. Oui, le NAS est un Lacie 2big exécutant une version de Linux sur ARM.

— therobyouknow

1

En fait, vous n'avez pas besoin de refuser la suppression, il vous suffit de supprimer Supprimer des entrées de contrôle d'accès existantes. (Refuser les ACE rend les choses plus complexes, ce qui n'est généralement pas un bon cours à long terme.)

— Richard

2

@Richard: AFAIK, la suppression nécessite la désactivation complète de l'héritage ACL pour ce fichier, ce qui le rend encore plus complexe à la fin.

— Grawity

Je suis d'accord avec Grawity. Refuser l'autorisation de supprimer est la voie à suivre. Si l'autorisation de partage est configurée pour être modifiée, le refus bloquera toujours la suppression, tandis que le laisser vide autorisera les suppressions.

— surfasb

26

Sous Linux, vous pouvez créer un lien dur. Ensuite, vous pourrez y écrire et "le supprimer", mais vous ne supprimerez que la référence de votre répertoire. L'autre lien dur pointe toujours sur le contenu du fichier, il ne sera donc pas supprimé de toute façon.

Dans le monde Unix, vous ne "supprimez" pas les fichiers. Vous venez de réduire le nombre de liens durs vers elle. Quand rien d'autre ne le pointe, l'espace est considéré comme libre et peut être utilisé…

— woliveirajr
source

2

Bonne idée. Je ne sais pas si @Rob peut créer des liens durs sur son NAS, mais s’il le peut, c’est une solution très intelligente.

— CarlF

1

+1 Je pourrais le combiner avec la réponse acceptée si possible. ou séparément si non. +1 pour sortir des sentiers battus, comme dit. Cependant, le partage linux en question est un lecteur NAS, il est impossible de savoir quelles installations de la console sont disponibles, il s’agit d’une forme de Linux intégrée ou semi-intégrée. +1 quand même car cela pourrait aider d’autres personnes qui ont un ordinateur de bureau ou un ordinateur Linux régulier faisant office de partage.

— therobyouknow

2

La même technique devrait fonctionner avec NTFS.

— Rotsor

+1 RBerteig et +1 CarlF pour la prise en charge de la solution woliveirajr.

— therobyouknow

12

Sauvegardes. Vous ne pouvez pas réellement protéger un fichier en écriture contre les dommages, même si vous pouvez le supprimer. Sauvegardez-le quotidiennement.

— CarlF
source

4

+1 Faites cela peu importe ce que les autres ceintures et bretelles sont appliquées.

— RBerteig

+1 CarlF et +1 RBerteig. Entièrement d'accord. Les fichiers sont également tous sauvegardés sur des supports optiques (DVD-R, + R, + R DL et Blu-ray 25 Go et dl 50 Go). Je peux aussi envisager un deuxième disque dur.

— therobyouknow

J'ajouterais que j'ai des sauvegardes des fichiers dans le volume TrueCrypt qui est le fichier conteneur. Pas le volume TrueCrypt lui-même.

— therobyouknow

0

En plus des réponses précédentes, je souhaiterais jeter un oeil sur selinux. Là, vous pouvez définir de jolies limitations granulaires.

— Niels Basjes
source

0

Sur un système de fichiers de type vache comme btrfs, vous pouvez y parvenir en utilisant des sous-volumes + instantanés ou cp avec --reflink = toujours, vous obtiendrez autant de fichiers que vous le souhaitez, qui consommeront autant d’espace qu'un + frais généraux (mais sans un nombre insensé de copies ou d'instantanés spécialement associés à des fichiers de petite taille, cela ne devrait pas être perceptible) jusqu'à ce qu'ils soient modifiés, auquel cas seules les parties modifiées ont été stockées séparément et le reste est toujours partagé. Ensuite, définissez les autorisations sur chaque élément séparément (pour réaliser ce que vous voulez, créez régulièrement un instantané ou une copie avec des autorisations en lecture seule (et montez-le éventuellement, que ce soit un instantané ou un fichier, utilisez chattr + i n’écrivez pas ou ne modifiez pas le fichier même si vous avez des permissions en écriture) sur une copie si vous êtes paranoïaque).

— orange_juice6000
source

0

Sous UNIX "standard", il semble impossible de protéger un seul fichier de la suppression si le répertoire est inscriptible. Intuitivement, on pourrait s’attendre à ce que le fait de supprimer la protection w des bits de mode avec «chmod» protège contre la suppression, mais CECI N'EST PAS LE CAS. De même, dans AFS, vous ne pouvez pas empêcher la suppression de fichiers individuels, car les entrées de la liste de contrôle d'accès (sans ou avec l'autorisation «d» correspondante) s'appliquent uniquement au répertoire dans son ensemble.

— Klaus Engelhardt
source