@ 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 
Pourtant, tu es bien dans ton répertoire perso.
[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.
[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
Pourtant, tu es bien dans ton répertoire perso.[/quote]
euh j’ai aucun fichier qui apartienne a root avec un utilisateur neuf ?
[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… 
fr.wikipedia.org/wiki/UNIX
fr.wikipedia.org/wiki/Permissions_Unix
Bonne lecture.
En effet, bizarre 
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 
[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]
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.
En effet, costaud ce “chattr” 
Je pense aussi que ça répond parfaitement à l’attente de Panthere.
Merci pour la réponse
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 
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”.
fait 
tu déplace dans T & A ?
ou je fait jut un nouveau poste qui abrege celui ci ?
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.
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]
@ Panthere :
J’ai fait une division du sujet dans T&A, au nom de NooP.