Je n'arrive pas à comprendre comment les liens durs sont pris en
compte dans le calcul de l'espace qu'occupent des données sur un
support.
Par exemple : j'ai un fichier de 1 Mo. J'en créé un lien dur. Cela ne
devrait pas diminuer l'espace disque occupé, puisque je ne fais
qu'ajouter une référence vers ce fichier. Si je vérifie avec la
commande du, la taille occupée par le répertoire ne change en effet
pas (toujours 1 Mo).
Or, l'explorateur de fichiers de KDE, konqueror, me dit que le
répertoire contient 2 Mo de données, que ce soit dans l'affichage de
la barre d'état ou en demandant les propriétés du dossier. De même
avec nautilus de Gnome. Peut-on considérer que c'est un bug ?
D'autres part, soient les commandes ln truc truc2 puis ln truc2
truc3. Est-ce que truc3 sera un lien dur du lien dur truc2 ou de
truc ? Vu le résultat de ls -l, je penche pour la 2e solution ; mais
ce que je ne comprends pas, c'est pourquoi : il est donc impossible
de faire un lien dur vers un lien dur ?
Non, c'est juste pour eviter de faire des boucles quand on parcourt le systeme de fichier. Eviter quelque chose du genre ln .. toto C'est possible avec les liens symboliques, mais ils permettent de differencier facilement le vrai repertoire du lien, donc, les utilitaire de type find, y font attention.
Ceci n'est pas un vrai problème. Les vrais problèmes sont: - si j'ai deux liens sur un répertoire, que se passe-t-il quand je fais "cd .." ? - les liens sur les répertoires permettraient de s'échapper facilement d'un chroot. C'est un trou de sécurité tellement énorme que ça justifie, en soi, l'interdiction de ces liens.
Issu de "Programmation linux 2.0", par Rémy Card, Eric Dumas et Franck Mevel. p123-124 : "il est impossible de creer des liens sur les repertoires. En effet, l'existence de liens entre repertoires aurait pour effet de transformer l'arborescence des fichiers en graphe pouvant contenir des cycles, et le noyau pourrait boucler sans fin lors de la résolution de noms de fichiers".
Oui, on peut considérer que c'est un bug de Linux, puisque d'autres OS gèrent ces cas, mais ce n'est pas le problème de fond...
On Tue, 19 Apr 2005 15:01:00 +0200, news wrote:
l'indien wrote:
On Tue, 19 Apr 2005 08:41:46 +0200, news wrote:
Non, c'est juste pour eviter de faire des boucles quand on parcourt le
systeme de fichier. Eviter quelque chose du genre ln .. toto
C'est possible avec les liens symboliques, mais ils permettent de
differencier facilement le vrai repertoire du lien, donc, les utilitaire
de type find, y font attention.
Ceci n'est pas un vrai problème.
Les vrais problèmes sont:
- si j'ai deux liens sur un répertoire, que se passe-t-il quand je fais
"cd .." ?
- les liens sur les répertoires permettraient de s'échapper facilement
d'un chroot. C'est un trou de sécurité tellement énorme que ça
justifie, en soi, l'interdiction de ces liens.
Issu de "Programmation linux 2.0", par Rémy Card, Eric Dumas et Franck
Mevel.
p123-124 :
"il est impossible de creer des liens sur les repertoires. En effet,
l'existence de liens entre repertoires aurait pour effet de transformer
l'arborescence des fichiers en graphe pouvant contenir des cycles, et le
noyau pourrait boucler sans fin lors de la résolution de noms de fichiers".
Oui, on peut considérer que c'est un bug de Linux, puisque d'autres OS
gèrent ces cas, mais ce n'est pas le problème de fond...
Non, c'est juste pour eviter de faire des boucles quand on parcourt le systeme de fichier. Eviter quelque chose du genre ln .. toto C'est possible avec les liens symboliques, mais ils permettent de differencier facilement le vrai repertoire du lien, donc, les utilitaire de type find, y font attention.
Ceci n'est pas un vrai problème. Les vrais problèmes sont: - si j'ai deux liens sur un répertoire, que se passe-t-il quand je fais "cd .." ? - les liens sur les répertoires permettraient de s'échapper facilement d'un chroot. C'est un trou de sécurité tellement énorme que ça justifie, en soi, l'interdiction de ces liens.
Issu de "Programmation linux 2.0", par Rémy Card, Eric Dumas et Franck Mevel. p123-124 : "il est impossible de creer des liens sur les repertoires. En effet, l'existence de liens entre repertoires aurait pour effet de transformer l'arborescence des fichiers en graphe pouvant contenir des cycles, et le noyau pourrait boucler sans fin lors de la résolution de noms de fichiers".
Oui, on peut considérer que c'est un bug de Linux, puisque d'autres OS gèrent ces cas, mais ce n'est pas le problème de fond...
Nicolas George
l'indien wrote in message :
Absolument pas. Il y a plein de process qui ont besoin de redescendre. C'est loin d'être trivial.
Je ne suis pas d'accord. En trente seconde, j'ai trouvé une réponse à ce problème : le répertoire contient une entrée « .. » par lien dur, et c'est la première qui est utilisée quand c'est nécessaire. Pas de quoi fouetter un chat. Je suis sûr qu'il y a un paquet d'autres possibilités aussi simples.
Non. Il suffit de connaitre le numéro d'inode du répertoire sur lequel on veut créer le lien et c'est gagné. Et justement, on connait toujours le numéro d'inode du répertoire racine de la partition, donc il est trivial de remonter à celle-ci.
Qu'est-ce que tu racontes ? On ne peut pas faire un lien rien qu'en connaissant un numéro d'inode, heureusement !
Les boucles posent un problème à Linux et à la plupart des Unix, en effet, puisqu'ils considèrent que le filesystem est un arbre.
Si ce n'était que ça, il serait facile d'ajouter des tests qui vont bien.
Néanmoins, résoudre ce problème ne résoudrait pas le trou de sécurité lié aux liens sur les répertoires.
Pour le moment, tu n'as pas exhibé de tel trou.
Donc, ce n'est pas le point bloquant ici: s'il n'y avait que ce point à résoudre, les patches nécessaires auraient été fait, ce n'est pas si compliqué (le plus gros des patches est à faire dans fsck, en fait...).
Non, le _gros_ truc, c'est que le comptage de références n'est plus un critère pour savoir si un répertoire existe encore, il faudrait implémenter un garbage collector complet pour les répertoires.
l'indien wrote in message <pan.2005.04.19.22.06.54.101608@magic.fr>:
Absolument pas. Il y a plein de process qui ont besoin de redescendre.
C'est loin d'être trivial.
Je ne suis pas d'accord. En trente seconde, j'ai trouvé une réponse à ce
problème : le répertoire contient une entrée « .. » par lien dur, et c'est
la première qui est utilisée quand c'est nécessaire. Pas de quoi fouetter un
chat. Je suis sûr qu'il y a un paquet d'autres possibilités aussi simples.
Non. Il suffit de connaitre le numéro d'inode du répertoire sur lequel
on veut créer le lien et c'est gagné. Et justement, on connait toujours
le numéro d'inode du répertoire racine de la partition, donc il est
trivial de remonter à celle-ci.
Qu'est-ce que tu racontes ? On ne peut pas faire un lien rien qu'en
connaissant un numéro d'inode, heureusement !
Les boucles posent un problème à Linux et à la plupart des Unix, en
effet, puisqu'ils considèrent que le filesystem est un arbre.
Si ce n'était que ça, il serait facile d'ajouter des tests qui vont bien.
Néanmoins, résoudre ce problème ne
résoudrait pas le trou de sécurité lié aux liens sur les répertoires.
Pour le moment, tu n'as pas exhibé de tel trou.
Donc, ce n'est pas le point bloquant ici: s'il n'y avait que ce point à
résoudre, les patches nécessaires auraient été fait, ce n'est pas si
compliqué (le plus gros des patches est à faire dans fsck, en fait...).
Non, le _gros_ truc, c'est que le comptage de références n'est plus un
critère pour savoir si un répertoire existe encore, il faudrait implémenter
un garbage collector complet pour les répertoires.
Absolument pas. Il y a plein de process qui ont besoin de redescendre. C'est loin d'être trivial.
Je ne suis pas d'accord. En trente seconde, j'ai trouvé une réponse à ce problème : le répertoire contient une entrée « .. » par lien dur, et c'est la première qui est utilisée quand c'est nécessaire. Pas de quoi fouetter un chat. Je suis sûr qu'il y a un paquet d'autres possibilités aussi simples.
Non. Il suffit de connaitre le numéro d'inode du répertoire sur lequel on veut créer le lien et c'est gagné. Et justement, on connait toujours le numéro d'inode du répertoire racine de la partition, donc il est trivial de remonter à celle-ci.
Qu'est-ce que tu racontes ? On ne peut pas faire un lien rien qu'en connaissant un numéro d'inode, heureusement !
Les boucles posent un problème à Linux et à la plupart des Unix, en effet, puisqu'ils considèrent que le filesystem est un arbre.
Si ce n'était que ça, il serait facile d'ajouter des tests qui vont bien.
Néanmoins, résoudre ce problème ne résoudrait pas le trou de sécurité lié aux liens sur les répertoires.
Pour le moment, tu n'as pas exhibé de tel trou.
Donc, ce n'est pas le point bloquant ici: s'il n'y avait que ce point à résoudre, les patches nécessaires auraient été fait, ce n'est pas si compliqué (le plus gros des patches est à faire dans fsck, en fait...).
Non, le _gros_ truc, c'est que le comptage de références n'est plus un critère pour savoir si un répertoire existe encore, il faudrait implémenter un garbage collector complet pour les répertoires.
Matthieu Moy
Doug713705 writes:
Il n'y a, pour moi, rien d'absurde dans ce comportement. Le répertoire /save contient bien 78.6 Go (en tout cas s'il fallait en sauvegarder son contenu exact, c'est la quantité de données qu'il faudrait s'attendre à avoir à stocker).
Si tu le fais "bêtement", oui. Mais un bon système de sauvegarde gère correctement les liens en dur tout comme les liens symboliques. A commencer par GNU tar, d'ailleurs (je pensais pas, mais je viens de vaire l'expérience).
Bon, on pourrait disserter longtemps sur quel est le bon comportement et quel est le mauvais (il faudrait déjà avoir une définition correcte de « taille » ...), mais moi, je trouve le comportement de "du" bien plus logique :
$ du -sh * 48M bazaar--devo--1.4--patch-1 48M bazaar--devo--1.4--patch-2 48M bazaar--devo--1.4--patch-3 $ du -sh 53M . $
La taille de ma maison ne dépend pas du nombre de portes ... ;-)
Il n'y a, pour moi, rien d'absurde dans ce comportement. Le répertoire /save
contient bien 78.6 Go (en tout cas s'il fallait en sauvegarder son contenu
exact, c'est la quantité de données qu'il faudrait s'attendre à avoir à
stocker).
Si tu le fais "bêtement", oui. Mais un bon système de sauvegarde gère
correctement les liens en dur tout comme les liens symboliques. A
commencer par GNU tar, d'ailleurs (je pensais pas, mais je viens de
vaire l'expérience).
Bon, on pourrait disserter longtemps sur quel est le bon comportement
et quel est le mauvais (il faudrait déjà avoir une définition correcte
de « taille » ...), mais moi, je trouve le comportement de "du" bien
plus logique :
$ du -sh *
48M bazaar--devo--1.4--patch-1
48M bazaar--devo--1.4--patch-2
48M bazaar--devo--1.4--patch-3
$ du -sh
53M .
$
La taille de ma maison ne dépend pas du nombre de portes ... ;-)
Il n'y a, pour moi, rien d'absurde dans ce comportement. Le répertoire /save contient bien 78.6 Go (en tout cas s'il fallait en sauvegarder son contenu exact, c'est la quantité de données qu'il faudrait s'attendre à avoir à stocker).
Si tu le fais "bêtement", oui. Mais un bon système de sauvegarde gère correctement les liens en dur tout comme les liens symboliques. A commencer par GNU tar, d'ailleurs (je pensais pas, mais je viens de vaire l'expérience).
Bon, on pourrait disserter longtemps sur quel est le bon comportement et quel est le mauvais (il faudrait déjà avoir une définition correcte de « taille » ...), mais moi, je trouve le comportement de "du" bien plus logique :
$ du -sh * 48M bazaar--devo--1.4--patch-1 48M bazaar--devo--1.4--patch-2 48M bazaar--devo--1.4--patch-3 $ du -sh 53M . $
La taille de ma maison ne dépend pas du nombre de portes ... ;-)
-- Matthieu
Matthieu Moy
Nicolas George <nicolas$ writes:
l'indien wrote in message :
Absolument pas. Il y a plein de process qui ont besoin de redescendre. C'est loin d'être trivial.
Je ne suis pas d'accord. En trente seconde, j'ai trouvé une réponse à ce problème : le répertoire contient une entrée « .. » par lien dur, et c'est la première qui est utilisée quand c'est nécessaire. Pas de quoi fouetter un chat. Je suis sûr qu'il y a un paquet d'autres possibilités aussi simples.
Du coup, tu casses la symétrie du lien en dur. Et tu te retrouves avec quelque chose qui ressemble comme deux gouttes d'eau a un lien symbolique ... Ça limite fortement l'intérêt de la chose.
-- Matthieu
Nicolas George <nicolas$george@salle-s.org> writes:
l'indien wrote in message <pan.2005.04.19.22.06.54.101608@magic.fr>:
Absolument pas. Il y a plein de process qui ont besoin de redescendre.
C'est loin d'être trivial.
Je ne suis pas d'accord. En trente seconde, j'ai trouvé une réponse à ce
problème : le répertoire contient une entrée « .. » par lien dur, et c'est
la première qui est utilisée quand c'est nécessaire. Pas de quoi fouetter un
chat. Je suis sûr qu'il y a un paquet d'autres possibilités aussi simples.
Du coup, tu casses la symétrie du lien en dur. Et tu te retrouves avec
quelque chose qui ressemble comme deux gouttes d'eau a un lien
symbolique ... Ça limite fortement l'intérêt de la chose.
Absolument pas. Il y a plein de process qui ont besoin de redescendre. C'est loin d'être trivial.
Je ne suis pas d'accord. En trente seconde, j'ai trouvé une réponse à ce problème : le répertoire contient une entrée « .. » par lien dur, et c'est la première qui est utilisée quand c'est nécessaire. Pas de quoi fouetter un chat. Je suis sûr qu'il y a un paquet d'autres possibilités aussi simples.
Du coup, tu casses la symétrie du lien en dur. Et tu te retrouves avec quelque chose qui ressemble comme deux gouttes d'eau a un lien symbolique ... Ça limite fortement l'intérêt de la chose.
-- Matthieu
Matthieu Moy
l'indien writes:
Néanmoins, résoudre ce problème ne résoudrait pas le trou de sécurité lié aux liens sur les répertoires.
Sans doute, mais ceci dit, sur la plupart des OS, il n'y a pas besoin d'avoir de lien en dur sur des répertoirs pour pouvoir sortir d'un chroot. :-(
J'avais trouvé cet article très intéressant a ce propos :
« chroot(), sécurité illusoire ou illusion de sécurité ? » http://www.miscmag.com/articles/index.php3?page08
Néanmoins, résoudre ce problème ne résoudrait pas le trou de sécurité lié aux liens sur les répertoires.
Sans doute, mais ceci dit, sur la plupart des OS, il n'y a pas besoin d'avoir de lien en dur sur des répertoirs pour pouvoir sortir d'un chroot. :-(
J'avais trouvé cet article très intéressant a ce propos :
« chroot(), sécurité illusoire ou illusion de sécurité ? » http://www.miscmag.com/articles/index.php3?page08
-- Matthieu
news
l'indien wrote:
On Tue, 19 Apr 2005 13:53:11 +0000, Nicolas George wrote:
l'indien wrote in message :
Les vrais problèmes sont: - si j'ai deux liens sur un répertoire, que se passe-t-il quand je fais "cd .." ?
Euh, bof, quand même, ça reste quelque chose d'assez anecdotique.
Absolument pas. Il y a plein de process qui ont besoin de redescendre. C'est loin d'être trivial.
Bon, rappelons nous que dans bash par exemple, il y'a une variable d'environnement qui donne le chemin depuis la racine. Il devient trivial de l'utiliser pour redescendre. Mais l'hypothese de depart etant qu'il n 'y a pas de cycle ne la rend pas necessaire. Si qq1 avait decide de faire un fs avec des cycles, il est a peu pres certain qu'il y aurait une solution pour que ce genre de choses fonctionne. A croire qu'il n'y en a pas besoin....
l'indien wrote:
On Tue, 19 Apr 2005 13:53:11 +0000, Nicolas George wrote:
l'indien wrote in message <pan.2005.04.19.12.41.23.986567@magic.fr>:
Les vrais problèmes sont:
- si j'ai deux liens sur un répertoire, que se passe-t-il quand je fais
"cd .." ?
Euh, bof, quand même, ça reste quelque chose d'assez anecdotique.
Absolument pas. Il y a plein de process qui ont besoin de redescendre.
C'est loin d'être trivial.
Bon, rappelons nous que dans bash par exemple, il y'a une variable
d'environnement qui donne le chemin depuis la racine. Il devient trivial
de l'utiliser pour redescendre. Mais l'hypothese de depart etant qu'il n
'y a pas de cycle ne la rend pas necessaire.
Si qq1 avait decide de faire un fs avec des cycles, il est a peu pres
certain qu'il y aurait une solution pour que ce genre de choses
fonctionne. A croire qu'il n'y en a pas besoin....
On Tue, 19 Apr 2005 13:53:11 +0000, Nicolas George wrote:
l'indien wrote in message :
Les vrais problèmes sont: - si j'ai deux liens sur un répertoire, que se passe-t-il quand je fais "cd .." ?
Euh, bof, quand même, ça reste quelque chose d'assez anecdotique.
Absolument pas. Il y a plein de process qui ont besoin de redescendre. C'est loin d'être trivial.
Bon, rappelons nous que dans bash par exemple, il y'a une variable d'environnement qui donne le chemin depuis la racine. Il devient trivial de l'utiliser pour redescendre. Mais l'hypothese de depart etant qu'il n 'y a pas de cycle ne la rend pas necessaire. Si qq1 avait decide de faire un fs avec des cycles, il est a peu pres certain qu'il y aurait une solution pour que ce genre de choses fonctionne. A croire qu'il n'y en a pas besoin....
news
Nicolas George wrote:
l'indien wrote in message :
Absolument pas. Il y a plein de process qui ont besoin de redescendre. C'est loin d'être trivial.
Je ne suis pas d'accord. En trente seconde, j'ai trouvé une réponse à ce problème : le répertoire contient une entrée « .. » par lien dur, et c'est la première qui est utilisée quand c'est nécessaire. Pas de quoi fouetter un chat. Je suis sûr qu'il y a un paquet d'autres possibilités aussi simples.
Non, ca c'est dans l'hypothese d'un arbre. Dans le cas d'un graphe .. aurait certainement une autre semantique.
Nicolas George wrote:
l'indien wrote in message <pan.2005.04.19.22.06.54.101608@magic.fr>:
Absolument pas. Il y a plein de process qui ont besoin de redescendre.
C'est loin d'être trivial.
Je ne suis pas d'accord. En trente seconde, j'ai trouvé une réponse à ce
problème : le répertoire contient une entrée « .. » par lien dur, et c'est
la première qui est utilisée quand c'est nécessaire. Pas de quoi fouetter un
chat. Je suis sûr qu'il y a un paquet d'autres possibilités aussi simples.
Non, ca c'est dans l'hypothese d'un arbre.
Dans le cas d'un graphe .. aurait certainement une autre semantique.
Absolument pas. Il y a plein de process qui ont besoin de redescendre. C'est loin d'être trivial.
Je ne suis pas d'accord. En trente seconde, j'ai trouvé une réponse à ce problème : le répertoire contient une entrée « .. » par lien dur, et c'est la première qui est utilisée quand c'est nécessaire. Pas de quoi fouetter un chat. Je suis sûr qu'il y a un paquet d'autres possibilités aussi simples.
Non, ca c'est dans l'hypothese d'un arbre. Dans le cas d'un graphe .. aurait certainement une autre semantique.
news
Matthieu Moy wrote:
l'indien writes:
Néanmoins, résoudre ce problème ne résoudrait pas le trou de sécurité lié aux liens sur les répertoires.
Sans doute, mais ceci dit, sur la plupart des OS, il n'y a pas besoin d'avoir de lien en dur sur des répertoirs pour pouvoir sortir d'un chroot. :-(
J'avais trouvé cet article très intéressant a ce propos :
« chroot(), sécurité illusoire ou illusion de sécurité ? » http://www.miscmag.com/articles/index.php3?page08
Disons que pour qu'un chroot soit efficace il faut verifier pas mal de choses et c'est pas si evident. Cela dit ca peut ralentir un peu un attaquant.
