Rendre impossible la modification des droits d'un fichier

Support Debian
#14

Le problème vient du répertoire contenant le fichier et non de son propriétaire.

Exemple :

  1. Je crée mon répertoire
    mkdir toto
    ls -l toto
    -> drwxr-xr-x 2 vincent users 4,0K 2011-05-31 21:21 toto/

  2. Je crée mon fichier
    cd toto
    touch titi

  3. Je modifie les droits de titi
    chmod 0000 titi
    ls -l titi
    -> ---------- 1 vincent users 0 2011-05-31 21:21 titi

  4. Je supprime le fichier
    rm -f titi
    ls -l titi
    -> ls: impossible d’accéder à titi: Aucun fichier ou dossier de ce type

Résultat : le fichier est bien supprimé

  1. Je recrée le fichier titi
    touch titi
    chmod 0000 titi

  2. Mais je modifie les droits du répertoire toto afin de lui retirer les droits de modification
    cd …
    chmod u-w toto
    ls -ld toto
    -> dr-xr-xr-x 2 vincent users 4,0K 2011-05-31 21:24 toto/

  3. et j’essaie de supprimer titi
    cd toto
    rm -f titi
    -> rm: impossible de supprimer «titi»: Permission non accordée

Résultat : Suppression impossible !!!

#15

[quote=“vvanholl2”]Le problème vient du répertoire contenant le fichier et non de son propriétaire.
[/quote]
il me semble la,que tu déplace le probleme

pis si c est le répertoire de l’utilisateur-> ~
tu croit qu’il va ecrire comment dedant quand il va ce loguer? :whistle:

#16

Yap

je suis presque d’accord , mai un truc coince, c’est un fichier root pas celui d’utilisateur standard. imagine que c’est un fichier
que tu doit mettre dans ~ et que celui ci ne doit pas y toucher (dison que ce fichier lui interdit de faire quelque chose), s’il peux le supprimer bah tu peux lui coller tout les droit que tu veux sa changera pas le problème.

#17

Eventuellement tu peut placer le sticky bit sur ta home directory, ce qui n’autorisera que le propriétaire du fichier (ou root) à supprimer le fichier.

#18

[quote=“panthere”]Yap

je suis presque d’accord , mai un truc coince, c’est un fichier root pas celui d’utilisateur standard. imagine que c’est un fichier
que tu doit mettre dans ~ et que celui ci ne doit pas y toucher (dison que ce fichier lui interdit de faire quelque chose), s’il peux le supprimer bah tu peux lui coller tout les droit que tu veux sa changera pas le problème.[/quote]
Imagination ou pas, ~ n’est pas la place de ce genre de fichier …
“It’s not a bug, it’s a feature”

#19

Ce comportement est tout ce qui est de plus normal.

/home/test appartient à l’utilisateur test, et cet utilisateur à les droits rwx sur son répertoire, ce qui veut dire qu’il peut supprimer ce qui est dedans.

Comme test est propriétaire de SON répertoire, il est (et encore heureux) autorisé à virer de celui ci tout ce qui ne lui plait pas.
De même qu’en tant qu’utilisateur, tu peux modifier ton fichier et l’enregistrer. Par contre, il n’appartiendra plus à root:root, mais à test une fois celui ci modifié.

Donc, comme cela à été dit par yap22 et vvanholl2, les droits que vous avez sur un fichier son aussi, mais surtout, rattachés aux droits du répertoire parent.

Vous pouvez faire l’essai inverse : Créez un répertoire, attribuez le à root:root, et placez dedans un fichier à votre nom. Vous ne pouvez pas le supprimer.

Et la vrai explication, c’est que tout est fichier sous *nix. Vous pouvez voir un répertoire de cette façon :

On comprends mieux pourquoi pour supprimer un fichier du répertoire test, il faut pouvoir modifier le fichier /home/test afin de retirer la ligne correspondant au fichier. Si ce fichier (Que nous appelons répertoire) appartient à root, un utilisateur ne peut simplement pas le modifier. A l’inverse, si ce fichier vous appartient, vous pouvez supprimer la ligne correspondant au fichier incriminé, et ce même si c’est root qui l’a créé.

Juste pour la blague, ne le prends pas mal :

Tu as du rater 50 ans de gestion de droits Unix :wink:

#20

[quote=“NooP”]

Tu as du rater 50 ans de gestion de droits Unix :wink:[/quote]

c’est certain les droit il faut un bon moment avant d’avoir fait le tour. mai bon 50 ans j’aurai pris un coup de vieux là :laughing:

bon tournon le probleme autrement :005
vu que l’utilisateur a les droit sur son home, Comment je fait pour éviter qu’il modifie et vire un fichier important,je lui fait confiance :snooty: ?
10 minute plus tard: :073 tu revien re-cree le fichier ?

#21

@ Noop :
pas d’accord.
Tu vas dans ton /home/toi
tu as certain fichiers qui appartiennent à root
essaie de les supprimer, il sont en 755 :018
Pourtant, tu es bien dans ton répertoire perso.

#22

[quote]bon tournon le probleme autrement
vu que l’utilisateur a les droit sur son home, Comment je fait pour éviter qu’il modifie et vire un fichier important,je lui fait confiance ?
[/quote]
J’avoue, c’est une bonne question… Car meme si on place le fichier en question dans un repertoire specifique dans lequel on interdit la suppression des fichiers, le proprietaire du repertoire pourra toujours se reattribuer les droits de suppression dans le repertoire et donc virer le fichier qui se trouve dedans.

#23

[quote=“ricardo”]@ Noop :
pas d’accord.
Tu vas dans ton /home/toi
tu as certain fichiers qui appartiennent à root
essaie de les supprimer, il sont en 755 :018
Pourtant, tu es bien dans ton répertoire perso.[/quote]
euh j’ai aucun fichier qui apartienne a root avec un utilisateur neuf ?

#24

[code]whoami

root

useradd -u 2000 -g 100 -m -s /bin/bash test
chmod 700 /home/test
cd /home
ls -al

drwxr-x–x 6 root users 4096 2011-06-01 11:41 .
drwxr-xr-x 25 root root 4096 2011-05-30 15:03 …
drwx------ 2 test users 4096 2011-06-01 11:41 test

cd test
echo “Essai” > Truc
ls -al

drwx------ 2 test users 4096 2011-06-01 11:44 ./
drwxr-x–x 6 root users 4096 2011-06-01 11:41 …/
-rw-r–r-- 1 test users 220 2010-04-19 04:15 .bash_logout
-rw-r–r-- 1 test users 3103 2010-04-19 04:15 .bashrc
-rw-r–r-- 1 test users 675 2010-04-19 04:15 .profile
-rw-r–r-- 1 root root 6 2011-06-01 11:42 Truc

su - test

whoami

test

pwd

/home/test

ls -al

drwx------ 2 test users 4096 2011-06-01 11:44 .
drwxr-x–x 6 root users 4096 2011-06-01 11:41 …
-rw-r–r-- 1 test users 220 2010-04-19 04:15 .bash_logout
-rw-r–r-- 1 test users 3103 2010-04-19 04:15 .bashrc
-rw-r–r-- 1 test users 675 2010-04-19 04:15 .profile
-rw-r–r-- 1 root root 6 2011-06-01 11:42 Truc

cat Truc
Essai

rm Truc
rm : supprimer fichier standard (protégé en écriture) «Truc» ? o

ls -al
drwx------ 2 test users 4096 2011-06-01 11:46 .
drwxr-x–x 6 root users 4096 2011-06-01 11:41 …
-rw-r–r-- 1 test users 220 2010-04-19 04:15 .bash_logout
-rw-r–r-- 1 test users 3103 2010-04-19 04:15 .bashrc
-rw-r–r-- 1 test users 675 2010-04-19 04:15 .profile

^D
userdel -r test

[/code]

Ben non, tu vois, mon utilisateur test peut parfaitement supprimer un fichier appartenant à root qui se trouve dans son répertoire.
Si tu veux parvenir à tes fins, il faut procéder de la sorte :

[code]whoami

root

useradd -u 2000 -m -s /bin/bash test
chown root:test /home/test
chmod 1770 /home/test
cd /home
ls -al

drwxr-x–x 6 root users 4096 2011-06-01 12:12 .
drwxr-xr-x 25 root root 4096 2011-05-30 15:03 …
drwxrwx–T 2 root test 4096 2011-06-01 12:12 test

cd test
ls -al

drwxrwx–T 2 root test 4096 2011-06-01 12:12 .
drwxr-x–x 6 root users 4096 2011-06-01 12:12 …
-rw-r–r-- 1 test test 220 2010-04-19 04:15 .bash_logout
-rw-r–r-- 1 test test 3103 2010-04-19 04:15 .bashrc
-rw-r–r-- 1 test test 675 2010-04-19 04:15 .profile

echo “Essai” > Truc
ls -al

-rw-r–r-- 1 test test 220 2010-04-19 04:15 .bash_logout
-rw-r–r-- 1 test test 3103 2010-04-19 04:15 .bashrc
-rw-r–r-- 1 test test 675 2010-04-19 04:15 .profile
-rw-r–r-- 1 root root 6 2011-06-01 12:15 Truc

su - test

whoami

test

pwd

/home/test

ls -al

drwxrwx–T 2 root test 4096 2011-06-01 12:15 .
drwxr-x–x 6 root users 4096 2011-06-01 12:12 …
-rw-r–r-- 1 test test 220 2010-04-19 04:15 .bash_logout
-rw-r–r-- 1 test test 3103 2010-04-19 04:15 .bashrc
-rw-r–r-- 1 test test 675 2010-04-19 04:15 .profile
-rw-r–r-- 1 root root 6 2011-06-01 12:15 Truc

cat Truc
Essai

rm Truc
rm : supprimer fichier standard (protégé en écriture) «Truc» ? o
rm: impossible de supprimer «Truc»: Opération non permise

ls -al

drwxrwx–T 2 root test 4096 2011-06-01 12:15 .
drwxr-x–x 6 root users 4096 2011-06-01 12:12 …
-rw-r–r-- 1 test test 220 2010-04-19 04:15 .bash_logout
-rw-r–r-- 1 test test 3103 2010-04-19 04:15 .bashrc
-rw-r–r-- 1 test test 675 2010-04-19 04:15 .profile
-rw-r–r-- 1 root root 6 2011-06-01 12:15 Truc

echo “Le fichier de Test” > Machin
ls -al

drwxrwx–T 2 root test 4096 2011-06-01 12:17 .
drwxr-x–x 6 root users 4096 2011-06-01 12:12 …
-rw-r–r-- 1 test test 220 2010-04-19 04:15 .bash_logout
-rw-r–r-- 1 test test 3103 2010-04-19 04:15 .bashrc
-rw-r–r-- 1 test test 12 2011-06-01 12:17 Machin
-rw-r–r-- 1 test test 675 2010-04-19 04:15 .profile
-rw-r–r-- 1 root root 6 2011-06-01 12:15 Truc

[/code]

En fait, le répertoire /home/test n’appartient pas à test, mais à root. On place les droits d’écriture sur le groupe ‘test’ (Qui est créé automatiquement lorsque qu’on omet de spécifier un groupe principal lors de la commande useradd) ainsi que le sticky bit, pour que les fichiers créés dans ce répertoire ne soient modifiables et supprimables QUE par celui qui les à créés.

Toutefois, cela peut poser problème pour certaines commandes qui vérifient que le $HOME appartient bien à l’utilisateur :

[code]whoami

root

userdel -r test
userdel : /home/test n’appartient pas à test, non supprimé

ls -al /home

drwxr-x–x 6 root users 4096 2011-06-01 12:26 .
drwxr-xr-x 25 root root 4096 2011-05-30 15:03 …
drwxrwx–T 2 root 2000 4096 2011-06-01 12:26 test

rm -Rf /home/test

[/code]

Il faut, de plus, faire bien attention à ce que chaque utilisateur ait son propre groupe, car comme cette solution travaille sur les droits de groupe plutôt que sur les droits de l’utilisateur, sinon toutes les personnes d’un même groupe auront le droit d’ajouter des fichiers et de lire dans le /home d’un autre utilisateur. Le pire, c’est qu’un fichier ‘Test2’ ajouté par l’utilisateur ‘test2’ dans le répertoire /home/test ne sera pas supprimable par l’utilisateur ‘test’. Cela peut aussi entrainer d’énormes problèmes de sécurité (Création par exemple d’un .profile, plaçant le path comme ceci : export PATH=/home/test2/bin:$PATH). Dans ce cas, lorsque test voudra par exemple exécuter une commande (passwd ?), si test2 à créé /home/test2/bin/passwd, celui ci sera exécuté AVANT l’utilitaire système se trouvant dans /sbin/passwd. Test2 peut alors récupérer sans problème le passwd de l’utilisateur ‘test’.

PS : [quote]@ Noop :
pas d’accord.[/quote]

Ce n’est pas une histoire d’être d’accord où pas avec moi, ce n’est pas moi qui à défini les droits Unix, j’étais pas encore tout à fait né fin des années 60 lors de la création d’Unix… :wink:

fr.wikipedia.org/wiki/UNIX
fr.wikipedia.org/wiki/Permissions_Unix

Bonne lecture.

#25

En effet, bizarre :unamused:
J’ai pratiqué autrement :
création sous root d’un fichier dans /home/ricardo
essai de suppression en simple user : il demande confirmation mais il obtempère
Ce n’est pas logique :open_mouth:

[code]ricardo@sid-sda8:~$ su -c 'touch /home/ricardo/fichierroot’
Mot de passe :

ricardo@sid-sda8:~$ su -c 'nano /home/ricardo/fichierroot’
POUR QU’IL NE SOIT PAS VIDE = BLABLA
Mot de passe :

ricardo@sid-sda8:~$ ls -al /home/ricardo/fichierroot
-rw-r–r-- 1 root root 52 1 juin 12:43 /home/ricardo/fichierroot

ricardo@sid-sda8:~$ rm /home/ricardo/fichierroot
rm : supprimer fichier (protégé en écriture) « /home/ricardo/fichierroot » ? y

ricardo@sid-sda8:~$ ls -al /home/ricardo/fichierroot
ls: impossible d’accéder à /home/ricardo/fichierroot: Aucun fichier ou dossier de ce type

[/code]

#26

Au contraire, j’y vois une certaine logique :

Supposons :

Tu (test) as une boite qui t’appartient.
Je (root) suis ton supérieur hiérarchique. Je mets un objet dans cette boite (fichier Truc).
Trouverais tu normal de ne pas pouvoir enlever cet objet de TA boite, sur le simple fait que j’aie des droits plus élevés que toi ?

Non ! Cette boite est la tienne, et tu as le droit d’y faire ce que tu veux.

Par contre, il aurait été intéressant que tu nous explique ce que tu souhaite modifier pour les utilisateurs, car il existe très certainement une autre méthode pour le réaliser que verrouiller un fichier dans le répertoire /home.

Ah, au fait, tu peux bloquer un fichier grace à ‘chattr’. Je n’y pense jamais à celui là :

[code]whoami

root

useradd -u 2000 -m -s /bin/bash test
chmod 700 /home/test
cd /home
ls -al

drwxr-x–x 6 root users 4096 2011-06-01 13:16 .
drwxr-xr-x 25 root root 4096 2011-05-30 15:03 …
drwx------ 2 test test 4096 2011-06-01 13:16 test

cd test
echo “Essai” > Truc

ls -al

drwx------ 2 test test 4096 2011-06-01 13:17 .
drwxr-x–x 6 root users 4096 2011-06-01 13:16 …
-rw-r–r-- 1 test test 220 2010-04-19 04:15 .bash_logout
-rw-r–r-- 1 test test 3103 2010-04-19 04:15 .bashrc
-rw-r–r-- 1 test test 675 2010-04-19 04:15 .profile
-rw-r–r-- 1 root root 6 2011-06-01 13:17 Truc

lsattr Truc

-----------------e- Truc

chattr +i Truc
lsattr Truc

----i------------e- Truc

su - test

whoami

test

pwd

/home/test

ls -al

drwx------ 2 test test 4096 2011-06-01 13:17 .
drwxr-x–x 6 root users 4096 2011-06-01 13:16 …
-rw-r–r-- 1 test test 220 2010-04-19 04:15 .bash_logout
-rw-r–r-- 1 test test 3103 2010-04-19 04:15 .bashrc
-rw-r–r-- 1 test test 675 2010-04-19 04:15 .profile
-rw-r–r-- 1 root root 6 2011-06-01 13:17 Truc

rm Truc
rm : supprimer fichier standard (protégé en écriture) «Truc» ? o
rm: impossible de supprimer «Truc»: Opération non permise

chattr -i Truc
chattr: Permission non accordée lors de l’initialisation des drapeaux sur Truc

chown test:test Truc
chown: changement de propriétaire pour «Truc»: Opération non permise

^D
userdel -r test
userdel : erreur lors de l’effacement du répertoire /home/test

rm -Rf /home/test
rm: impossible de supprimer «/home/test/Truc»: Opération non permise

chattr -R -i /home/test
rm -Rf /home/test

[/code]

Voila qui répond parfaitement à la question originelle, sans créer de faille de sécurité béante dans tes répertoires /home. Fais tout de même attention avec chattr, car comme tu peux le voir, un fichier auquel on à attribué le bit ‘immuable’ (+i) ne peut même pas être supprimé par root sans que celui ci ait auparavant supprimé ce bit.

#27

En effet, costaud ce “chattr” :023
Je pense aussi que ça répond parfaitement à l’attente de Panthere.

#28

Merci pour la réponse :023
Je pense que cette astuce devrai figurer dans le wiki avec un avertissement pour les débutant.

le pourquoi et bien:
une application modifie a nouveau un fichier que moi j’ai modifier dans le home et je ne veux plus qu’il y touche ni le modifie.
donc oui la sa prend son utiliter :slightly_smiling:

#29

Panthere, je te propose de modifier le titre de ton fil pour le retrouver plus facilement en cas de besoin.
Je verrai bien :
“Rendre impossible la modification des droits d’un fichier”.

#30

fait :slightly_smiling:
tu déplace dans T & A ?
ou je fait jut un nouveau poste qui abrege celui ci ?

#31

Tout a été dit sur l’aspect normal de ces comportements. Attention avec l’attribut -i, le propriétaire lui même du fichier ne peut modifier ou changer le fichier.

#32

NooP l’avait bien précisé :

[quote]
Voila qui répond parfaitement à la question originelle, sans créer de faille de sécurité béante dans tes répertoires /home. Fais tout de même attention avec chattr, car comme tu peux le voir, un fichier auquel on à attribué le bit ‘immuable’ (+i) ne peut même pas être supprimé par root sans que celui ci ait auparavant supprimé ce bit.[/quote]

#33

@ Panthere :
J’ai fait une division du sujet dans T&A, au nom de NooP.