Je cherche un moyen de régler les permissions/attributs sur un fichier de
telle sorte que le propriétaire (moi...) puisse le modifier comme il veut,
mais pas l'effacer. Je suis sur un système de fichier en ext3, sous Linux.
Pour la petite histoire, c'est un fichier de données relativement
important pour moi, qui est modifié uniquement par un certain logiciel,
mais qui a la mauvaise idée de se loger directement dans mon home, avec un
nom abscon, et qui risque de passer à la trappe par erreur un jour de
grand ménage de printemps si je le protège pas un peu...
Avec les attributs (chattr/lsattr), je peux le mettre en append-only (a),
il ne peut plus être effacé, mais ça n'a pas l'air de marcher pour écrire
dedans (je comprends pas pourquoi, d'ailleurs...) :
$ touch truc
$ lsattr truc
----------------- truc
$ cat > truc
toto
titi
^D
$ sudo chattr +a truc
$ lsattr truc
-----a----------- truc
$ cat truc
toto
titi
$ cat > truc
bash: truc: Opération non permise
$ rm truc
rm: ne peut enlever `truc': Opération non permise
$ sudo chattr -a truc
$ rm truc
$
Mais de toute façon, ça m'empécherait aussi d'effacer une partie du
contenu du fichier, je crois.
Y'a-t-il donc une solution pour que je puisse lire/écrire librement dans
mon fichier, mais pas l'effacer ?
--
Rémi Moyen
"Malgré les apparences, le temps est très varié à Nancy :
pluie, nuages, neige, brouillard, grêle, ..."
Stephane Chazelas writes: et mal orthographiée: est.invalide
Mal orthographiée peut être, mais c'est la norme à ma connaissance.
(Et je plains le pauvre qui héritera de ce nom de domaine quand il sera alloué).
C'est pas un nom de domaine mais juste une extension, et jamais il ne sera utilisé, par définition.
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
Stephane Chazelas
2003-11-26, 18:03(+01), Pascal Bourguignon:
Stephane Chazelas writes: et mal orthographiée: est.invalide (Et je plains le pauvre qui héritera de ce nom de domaine quand il sera alloué).
C'est justement mal orthographié exprès pour que ça n'arrive jamais. "test", "example" et "invalid" sont réservés et ne seront jamais attribués, RTFRFC ;).
Les DNS (voire les bibliothèques de résolution de nom) n'essaient même pas de résoudre ce nom en principe. C'est pour ça que t'en vois partout des ".invalid", c'est la façon recommandée d'invalider une adresse.
[...]
Il faut que le repertoire et le liens appartiennent à root par ex. :
Non, pas à root! Seulement à un autre utilisateur. Par exemple, pour un utilisateur toto, créer un compte toto-imp, etc: [...]
Pourquoi, « pas à root » ? Ça me semblait pourtant le plus approprié.
Parce qu'en passant par root on a le risque de faire une erreur catastrophique, et que ça ne marche pas (socialement) quand il y a plus de deux utilisateurs. [...]
Dans ce sens là, d'accord. Par contre, donner un fichier ou un répertoire à root est la plus forte protection qu'on puisse donner à ce répertoire (puisqu'il faut avoir les privilèges maximums pour le modifier, bon c'est vrai que déranger l'admin système à chaque fois qu'on veut le modifier, c'est pas très sympa).
(NB, ya une autre RFC et des études de typo-ergonomie qui recommandent de limiter la longueur des lignes de ses messages à moins de 65 caractères si on veut pinailler ;).
Stephane Chazelas <cette.adresse@est.invalid> writes:
et mal orthographiée: est.invalide
(Et je plains le pauvre qui héritera de ce nom de domaine quand il sera alloué).
C'est justement mal orthographié exprès pour que ça n'arrive
jamais. "test", "example" et "invalid" sont réservés et ne
seront jamais attribués, RTFRFC ;).
Les DNS (voire les bibliothèques de résolution de nom)
n'essaient même pas de résoudre ce nom en principe. C'est pour
ça que t'en vois partout des ".invalid", c'est la façon
recommandée d'invalider une adresse.
[...]
Il faut que le repertoire et le liens appartiennent à root par ex. :
Non, pas à root! Seulement à un autre utilisateur.
Par exemple, pour un utilisateur toto, créer un compte toto-imp, etc:
[...]
Pourquoi, « pas à root » ? Ça me semblait pourtant le plus
approprié.
Parce qu'en passant par root on a le risque de faire une erreur
catastrophique, et que ça ne marche pas (socialement) quand il y a
plus de deux utilisateurs.
[...]
Dans ce sens là, d'accord. Par contre, donner un fichier ou un
répertoire à root est la plus forte protection qu'on puisse
donner à ce répertoire (puisqu'il faut avoir les privilèges
maximums pour le modifier, bon c'est vrai que déranger
l'admin système à chaque fois qu'on veut le modifier, c'est pas
très sympa).
(NB, ya une autre RFC et des études de typo-ergonomie qui
recommandent de limiter la longueur des lignes de ses messages à
moins de 65 caractères si on veut pinailler ;).
Stephane Chazelas writes: et mal orthographiée: est.invalide (Et je plains le pauvre qui héritera de ce nom de domaine quand il sera alloué).
C'est justement mal orthographié exprès pour que ça n'arrive jamais. "test", "example" et "invalid" sont réservés et ne seront jamais attribués, RTFRFC ;).
Les DNS (voire les bibliothèques de résolution de nom) n'essaient même pas de résoudre ce nom en principe. C'est pour ça que t'en vois partout des ".invalid", c'est la façon recommandée d'invalider une adresse.
[...]
Il faut que le repertoire et le liens appartiennent à root par ex. :
Non, pas à root! Seulement à un autre utilisateur. Par exemple, pour un utilisateur toto, créer un compte toto-imp, etc: [...]
Pourquoi, « pas à root » ? Ça me semblait pourtant le plus approprié.
Parce qu'en passant par root on a le risque de faire une erreur catastrophique, et que ça ne marche pas (socialement) quand il y a plus de deux utilisateurs. [...]
Dans ce sens là, d'accord. Par contre, donner un fichier ou un répertoire à root est la plus forte protection qu'on puisse donner à ce répertoire (puisqu'il faut avoir les privilèges maximums pour le modifier, bon c'est vrai que déranger l'admin système à chaque fois qu'on veut le modifier, c'est pas très sympa).
(NB, ya une autre RFC et des études de typo-ergonomie qui recommandent de limiter la longueur des lignes de ses messages à moins de 65 caractères si on veut pinailler ;).
Avec les attributs (chattr/lsattr), je peux le mettre en append-only (a), il ne peut plus être effacé, mais ça n'a pas l'air de marcher pour écrire dedans (je comprends pas pourquoi, d'ailleurs...) :
Parce que tu ne fais pas de append justement.
$ touch truc $ lsattr truc ----------------- truc $ cat > truc toto titi ^D $ sudo chattr +a truc $ lsattr truc -----a----------- truc $ cat truc toto titi $ cat > truc bash: truc: Opération non permise $ rm truc rm: ne peut enlever `truc': Opération non permise $ sudo chattr -a truc $ rm truc $
Essai 'cat >> truc' ou 'echo "pouet" >> truc', ça marchera.
Mais de toute façon, ça m'empécherait aussi d'effacer une partie du contenu du fichier, je crois.
Il y a des chances oui.
Remi Moyen wrote:
Salut,
Salut,
Avec les attributs (chattr/lsattr), je peux le mettre en append-only (a),
il ne peut plus être effacé, mais ça n'a pas l'air de marcher pour écrire
dedans (je comprends pas pourquoi, d'ailleurs...) :
Parce que tu ne fais pas de append justement.
$ touch truc
$ lsattr truc
----------------- truc
$ cat > truc
toto
titi
^D
$ sudo chattr +a truc
$ lsattr truc
-----a----------- truc
$ cat truc
toto
titi
$ cat > truc
bash: truc: Opération non permise
$ rm truc
rm: ne peut enlever `truc': Opération non permise
$ sudo chattr -a truc
$ rm truc
$
Essai 'cat >> truc' ou 'echo "pouet" >> truc', ça marchera.
Mais de toute façon, ça m'empécherait aussi d'effacer une partie du
contenu du fichier, je crois.
Avec les attributs (chattr/lsattr), je peux le mettre en append-only (a), il ne peut plus être effacé, mais ça n'a pas l'air de marcher pour écrire dedans (je comprends pas pourquoi, d'ailleurs...) :
Parce que tu ne fais pas de append justement.
$ touch truc $ lsattr truc ----------------- truc $ cat > truc toto titi ^D $ sudo chattr +a truc $ lsattr truc -----a----------- truc $ cat truc toto titi $ cat > truc bash: truc: Opération non permise $ rm truc rm: ne peut enlever `truc': Opération non permise $ sudo chattr -a truc $ rm truc $
Essai 'cat >> truc' ou 'echo "pouet" >> truc', ça marchera.
Mais de toute façon, ça m'empécherait aussi d'effacer une partie du contenu du fichier, je crois.
Il y a des chances oui.
Remi Moyen
On Wed, 26 Nov 2003, Manu wrote:
Avec les attributs (chattr/lsattr), je peux le mettre en append-only (a), il ne peut plus être effacé, mais ça n'a pas l'air de marcher pour écrire dedans (je comprends pas pourquoi, d'ailleurs...) :
Parce que tu ne fais pas de append justement. [...]
Essai 'cat >> truc' ou 'echo "pouet" >> truc', ça marchera.
Groumpf, oui, bien sûr. Je fus très bête sur ce coup-là...
Merci de tes précisions ! -- Rémi Moyen "Malgré les apparences, le temps est très varié à Nancy : pluie, nuages, neige, brouillard, grêle, ..."
On Wed, 26 Nov 2003, Manu wrote:
Avec les attributs (chattr/lsattr), je peux le mettre en append-only (a),
il ne peut plus être effacé, mais ça n'a pas l'air de marcher pour écrire
dedans (je comprends pas pourquoi, d'ailleurs...) :
Parce que tu ne fais pas de append justement.
[...]
Essai 'cat >> truc' ou 'echo "pouet" >> truc', ça marchera.
Groumpf, oui, bien sûr. Je fus très bête sur ce coup-là...
Merci de tes précisions !
--
Rémi Moyen
"Malgré les apparences, le temps est très varié à Nancy :
pluie, nuages, neige, brouillard, grêle, ..."
Avec les attributs (chattr/lsattr), je peux le mettre en append-only (a), il ne peut plus être effacé, mais ça n'a pas l'air de marcher pour écrire dedans (je comprends pas pourquoi, d'ailleurs...) :
Parce que tu ne fais pas de append justement. [...]
Essai 'cat >> truc' ou 'echo "pouet" >> truc', ça marchera.
Groumpf, oui, bien sûr. Je fus très bête sur ce coup-là...
Merci de tes précisions ! -- Rémi Moyen "Malgré les apparences, le temps est très varié à Nancy : pluie, nuages, neige, brouillard, grêle, ..."
