Rendre impossible la modification des droits d'un fichier

Support Debian
#1

Hello

souci plutôt inquiétant :
pour tester
crée un utilisateur neuf: avec #adduser test
1 je me place

#cd /home/test touch truc chmod 0000 truc ls -la ---------- 1 root root 0 31 mai 01:26 truc

je passe sous l’utilisateur test --> startx – :2
je lancer krusader et je supprimer le fichier truc sans problème ??? (non l’appli est pas lancée en root)
sur un fichier systeme je peux pas en revanche :frowning:donc non c est vraiment pas en root)
note: que test ne fait pas partie autre que ceux fournis par default.

ce problème est présent sur 2 machine installerée il y a peux
debian squeez 6,0 config de base
j’ai rater quelque chose ou c est un bug serieux ?

#2

En effet, j’ai fais ton test et même résultat : je ne peux pas le lire avec cat (sauf en root) mais je peux le supprimer :unamused:
Maintenant, il est quand même peu fréquent de faire un fichier en 0000 :119

#3

hello
ben l’interet c’est de le proteger et donc de le fermer, 0000 c est plus simple et radical, donc c’est amha un bug de secu ,d’autre avis ?

#4

Et en 440 ? Comme ça il n’y a que root qui puisse le lire, et peut être que ça contourne le bug.

Sauf si tu veux vraiment qu’absolument personne ne puisse le lire (mais bon, dans ce cas, il sert à rien ^^)

#5

Salut,
Moi ça me semble normal. Il n’appartient à personne ce fichier, il est donc normal que n’importe qui puisse le supprimer.
Pour qu’il soit protégé, il faut qu’il soit au moins en 400.

#6

[quote=“lol”]Salut,
Moi ça me semble normal. Il n’appartient à personne ce fichier, il est donc normal que n’importe qui puisse le supprimer.
Pour qu’il soit protégé, il faut qu’il soit au moins en 400.[/quote]
Comment ?? :open_mouth:
il a partien a root, je vois pourquoi un utilisateur standard pourrai le supprimer… 0000 = 7777 ?? moi je dit bug tout de même
que root puisse le supprimer je dit pas mai la… :108

#7

[quote=“neeko”]Et en 440 ? Comme ça il n’y a que root qui puisse le lire, et peut être que ça contourne le bug.

Sauf si tu veux vraiment qu’absolument personne ne puisse le lire (mais bon, dans ce cas, il sert à rien ^^)[/quote]

et bien meme la je peux le supprimer … :open_mouth: euh sa crain … je fait un raport de bug ou pour la secu ?
edit meme en 0400 …

#8

Salut,

[quote=“panthere”]je fait un raport de bug ou pour la secu ?
edit meme en 0400 …[/quote]
Tu devrais plutôt trouver la liste qui va bien et poser la question.

#9

Pour qu’il y ait sécurité complète, il faudrait ptet que le fichier soit CRÉÉ par root et non pas par un user.

#10

touch = cree un fichier vide
tu peux faire l’essai:

[code]$su

touch truc

ls -la

chmod 0400 truc[/code]

le fichier appartient a root,cree par root et donc sa bug …

#11

[quote=“lol”]Salut,

[quote=“panthere”]je fait un raport de bug ou pour la secu ?
edit meme en 0400 …[/quote]
Tu devrais plutôt trouver la liste qui va bien et poser la question.[/quote]

je sais pas si c est sage de poster sa sur une liste :think: remarque sur un forum c’est pas mieux m’enfin… :005
bon la nui porte conseil, si demin je vois que c’est toujours louche je fait directement un rapport de bug c’est fait pour ça après tout (s’il arrive a comprend quelque chose a ce que je vai écrire hum… :slightly_smiling:
par contre je sai pas qu’elle est le paquet concerner ?

#12

[quote=“panthere”]bon la nui porte conseil, si demin je vois que c’est toujours louche je fait directement un rapport de bug c’est fait pour ça après tout (s’il arrive a comprend quelque chose a ce que je vai écrire hum… :slightly_smiling:
par contre je sai pas qu’elle est le paquet concerner ?[/quote]

Salut,
J’ai testé aussi et effectivement…

$ vdir essai ---------- 1 root root 33 31 mai 19:11 essai $ rm essai rm : supprimer fichier (protégé en écriture) « essai » ? o
Et zou… Effacé!
Par contre impossible de le lire ou de le modifier.
Encore une fois, il appartient à root, mais personne n’a aucun droits dessus (pas plus root que n’importe qui)… Donc ça ne me choque pas comme comportement!

Si tu veut protéger ton fichier:
chmod 400 !

#13

Bonjour,

Le fichier a été créé par un utilisateur (root) dans un dossier appartenant à un autre utilisateur (test).
Il peut le supprimer parce que le dossier lui appartient, non ?*

Un fichier dans mon HOME appartenant à root :

root@nanda:/home/yap# touch fic_rm
root@nanda:/home/yap# ls -lisa fic_rm 
8782528 0 -rw-r--r-- 1 root root 0 31 mai   20:58 fic_rm
root@nanda:/home/yap#

Je peux le supprimer :

yap@nanda:~$ rm fic_rm 
rm : supprimer fichier vide (protégé en écriture) « fic_rm » ? y
yap@nanda:~$ ls -lisa fic_rm
ls: impossible d'accéder à fic_rm: Aucun fichier ou dossier de ce type
yap@nanda:~$

Un dossier et un fichier appartenant à root dans mon HOME :

root@nanda:/home/yap# mkdir test_rm
root@nanda:/home/yap# touch test_rm/toto
root@nanda:/home/yap# ls -lisa test_rm/
total 8
10224503 4 drwxr-xr-x  2 root root 4096 31 mai   20:53 .
 8781825 4 drwx-----x 62 yap  yap  4096 31 mai   20:53 ..
10224504 0 -rw-r--r--  1 root root    0 31 mai   20:53 toto

Je ne peux pas supprimer le fichier ni le dossier :

yap@nanda:~$ cd test_rm/
yap@nanda:~/test_rm$ ls
toto
yap@nanda:~/test_rm$ rm toto 
rm : supprimer fichier vide (protégé en écriture) « toto » ? y
rm: impossible de supprimer « toto »: Permission non accordée
yap@nanda:~/test_rm$ cd 
yap@nanda:~$ rm -rf test_rm/
rm: impossible de supprimer « test_rm/toto »: Permission non accordée
#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 ?