Dans le cadre d'un développement, je dois reprendre un projet dont
le but est l'installation d'un package sur une machine, mais dans un
répertoire système (appartenant à root), et ce à partir d'un CD.
D'après ce que je comprends, sur la machine de création du CD, les
différentes commandes (cp, rm, mv, tar, mkdir, chmod, mount, umount ...)
sont copiées avec de nouveaux noms (du genre commande1, commande2 ....)
et se voient appliquer le sticky bit avec chmod 7755 (en étant root sur
cette
machine).
Ces fichiers sont copiés sur le CD-ROM, avec le package et le
programme d'installation, et ce dernier les utilise et semble pouvoir
installer le package comme s'il était root, sur une autre machine.
Celà me semble inconcevable, car si celà était possible, cela voudrait dire
que n'importe qui pourrait se faire passer pour root en ayant des commandes
avec le sticky bit positionné en étant root sur une autre machine.
D'où ma question : les droits root sont ils universels ? Comment UNIX
différencie
les droits du root de la machine et les droits positionné par un autre root
?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Nicolas George
"Ahimsa" wrote in message <45e1d501$0$27375$:
Dans le cadre d'un développement, je dois reprendre un projet dont le but est l'installation d'un package sur une machine, mais dans un répertoire système (appartenant à root), et ce à partir d'un CD.
D'après ce que je comprends, sur la machine de création du CD, les différentes commandes (cp, rm, mv, tar, mkdir, chmod, mount, umount ...) sont copiées avec de nouveaux noms (du genre commande1, commande2 ....) et se voient appliquer le sticky bit avec chmod 7755 (en étant root sur cette machine).
Ayé, j'ai vomi.
Ces fichiers sont copiés sur le CD-ROM, avec le package et le programme d'installation, et ce dernier les utilise et semble pouvoir installer le package comme s'il était root, sur une autre machine.
Celà me semble inconcevable, car si celà était possible, cela voudrait dire que n'importe qui pourrait se faire passer pour root en ayant des commandes avec le sticky bit positionné en étant root sur une autre machine.
(Ce n'est pas le sticky bit, c'est le bit SUID.)
Sur un système correctement configuré, les périphériques amovibles sont montés avec l'option nosuid, et le bit SUID n'a pas d'effet.
D'où ma question : les droits root sont ils universels ? Comment UNIX différencie les droits du root de la machine et les droits positionné par un autre root ?
Il n'y a pas de différence à ce niveau-là. Dès que le système voit une UID 0 et un bit SUID pris en compte, l'effet est le même.
Mais ici, le bit SUID ne devrait pas être pris en compte.
"Ahimsa" wrote in message <45e1d501$0$27375$ba4acef3@news.orange.fr>:
Dans le cadre d'un développement, je dois reprendre un projet dont
le but est l'installation d'un package sur une machine, mais dans un
répertoire système (appartenant à root), et ce à partir d'un CD.
D'après ce que je comprends, sur la machine de création du CD, les
différentes commandes (cp, rm, mv, tar, mkdir, chmod, mount, umount ...)
sont copiées avec de nouveaux noms (du genre commande1, commande2 ....)
et se voient appliquer le sticky bit avec chmod 7755 (en étant root sur
cette
machine).
Ayé, j'ai vomi.
Ces fichiers sont copiés sur le CD-ROM, avec le package et le
programme d'installation, et ce dernier les utilise et semble pouvoir
installer le package comme s'il était root, sur une autre machine.
Celà me semble inconcevable, car si celà était possible, cela voudrait dire
que n'importe qui pourrait se faire passer pour root en ayant des commandes
avec le sticky bit positionné en étant root sur une autre machine.
(Ce n'est pas le sticky bit, c'est le bit SUID.)
Sur un système correctement configuré, les périphériques amovibles sont
montés avec l'option nosuid, et le bit SUID n'a pas d'effet.
D'où ma question : les droits root sont ils universels ? Comment UNIX
différencie les droits du root de la machine et les droits positionné par
un autre root ?
Il n'y a pas de différence à ce niveau-là. Dès que le système voit une UID 0
et un bit SUID pris en compte, l'effet est le même.
Mais ici, le bit SUID ne devrait pas être pris en compte.
Dans le cadre d'un développement, je dois reprendre un projet dont le but est l'installation d'un package sur une machine, mais dans un répertoire système (appartenant à root), et ce à partir d'un CD.
D'après ce que je comprends, sur la machine de création du CD, les différentes commandes (cp, rm, mv, tar, mkdir, chmod, mount, umount ...) sont copiées avec de nouveaux noms (du genre commande1, commande2 ....) et se voient appliquer le sticky bit avec chmod 7755 (en étant root sur cette machine).
Ayé, j'ai vomi.
Ces fichiers sont copiés sur le CD-ROM, avec le package et le programme d'installation, et ce dernier les utilise et semble pouvoir installer le package comme s'il était root, sur une autre machine.
Celà me semble inconcevable, car si celà était possible, cela voudrait dire que n'importe qui pourrait se faire passer pour root en ayant des commandes avec le sticky bit positionné en étant root sur une autre machine.
(Ce n'est pas le sticky bit, c'est le bit SUID.)
Sur un système correctement configuré, les périphériques amovibles sont montés avec l'option nosuid, et le bit SUID n'a pas d'effet.
D'où ma question : les droits root sont ils universels ? Comment UNIX différencie les droits du root de la machine et les droits positionné par un autre root ?
Il n'y a pas de différence à ce niveau-là. Dès que le système voit une UID 0 et un bit SUID pris en compte, l'effet est le même.
Mais ici, le bit SUID ne devrait pas être pris en compte.
lhabert
"Ahimsa" :
D'après ce que je comprends, sur la machine de création du CD, les différentes commandes (cp, rm, mv, tar, mkdir, chmod, mount, umount ...) sont copiées avec de nouveaux noms (du genre commande1, commande2 ....) et se voient appliquer le sticky bit avec chmod 7755 (en étant root sur cette machine).
Il suffit de 4755, et le bit en question s'appelle setuid. Le bit sticky, il n'a de sens que sur les répertoires.
Ces fichiers sont copiés sur le CD-ROM, avec le package et le programme d'installation, et ce dernier les utilise et semble pouvoir installer le package comme s'il était root, sur une autre machine.
Cette technique est grotesque, et risque de ne pas marcher, cf plus loin. Il vaut mieux simplement demander à l'utilisateur de passer root pour lancer le programme d'installation.
Celà me semble inconcevable, car si celà était possible, cela voudrait dire que n'importe qui pourrait se faire passer pour root en ayant des commandes avec le sticky bit positionné en étant root sur une autre machine.
D'où ma question : les droits root sont ils universels ? Comment UNIX différencie les droits du root de la machine et les droits positionné par un autre root?
Dans le modèle unix traditionel, les supports de données amovibles, ça n'existe pas, seul root a le droit de monter des systèmes de fichiers, et il est censé s'assurer qu'il n'y a pas de bit s intempestifs dessus. De nos jours où l'on est bien obligé de laisser n'importe quel utilisateur monter un fs qu'il fournit sur un CD ou une clef USB, il y a effectivement un problème. Sous linux (j'imagine qu'il y a un truc similaire sur les autres OS), la solution retenue consiste en l'option de montage « nosuid », qui fait ignorer les bits suid et sgid par le noyau. Il faut d'ailleurs aussi l'option « nodev ». Et les systèmes permettant le montage automatique ou à la demande de l'utilisateur des fs amovibles activent ces options.
"Ahimsa" :
D'après ce que je comprends, sur la machine de création du CD, les
différentes commandes (cp, rm, mv, tar, mkdir, chmod, mount, umount ...)
sont copiées avec de nouveaux noms (du genre commande1, commande2 ....)
et se voient appliquer le sticky bit avec chmod 7755 (en étant root sur
cette machine).
Il suffit de 4755, et le bit en question s'appelle setuid. Le bit sticky, il
n'a de sens que sur les répertoires.
Ces fichiers sont copiés sur le CD-ROM, avec le package et le
programme d'installation, et ce dernier les utilise et semble pouvoir
installer le package comme s'il était root, sur une autre machine.
Cette technique est grotesque, et risque de ne pas marcher, cf plus loin. Il
vaut mieux simplement demander à l'utilisateur de passer root pour lancer le
programme d'installation.
Celà me semble inconcevable, car si celà était possible, cela voudrait dire
que n'importe qui pourrait se faire passer pour root en ayant des commandes
avec le sticky bit positionné en étant root sur une autre machine.
D'où ma question : les droits root sont ils universels ? Comment UNIX
différencie les droits du root de la machine et les droits positionné par
un autre root?
Dans le modèle unix traditionel, les supports de données amovibles, ça
n'existe pas, seul root a le droit de monter des systèmes de fichiers, et il
est censé s'assurer qu'il n'y a pas de bit s intempestifs dessus. De nos
jours où l'on est bien obligé de laisser n'importe quel utilisateur monter
un fs qu'il fournit sur un CD ou une clef USB, il y a effectivement un
problème. Sous linux (j'imagine qu'il y a un truc similaire sur les autres
OS), la solution retenue consiste en l'option de montage « nosuid », qui
fait ignorer les bits suid et sgid par le noyau. Il faut d'ailleurs aussi
l'option « nodev ». Et les systèmes permettant le montage automatique ou à
la demande de l'utilisateur des fs amovibles activent ces options.
D'après ce que je comprends, sur la machine de création du CD, les différentes commandes (cp, rm, mv, tar, mkdir, chmod, mount, umount ...) sont copiées avec de nouveaux noms (du genre commande1, commande2 ....) et se voient appliquer le sticky bit avec chmod 7755 (en étant root sur cette machine).
Il suffit de 4755, et le bit en question s'appelle setuid. Le bit sticky, il n'a de sens que sur les répertoires.
Ces fichiers sont copiés sur le CD-ROM, avec le package et le programme d'installation, et ce dernier les utilise et semble pouvoir installer le package comme s'il était root, sur une autre machine.
Cette technique est grotesque, et risque de ne pas marcher, cf plus loin. Il vaut mieux simplement demander à l'utilisateur de passer root pour lancer le programme d'installation.
Celà me semble inconcevable, car si celà était possible, cela voudrait dire que n'importe qui pourrait se faire passer pour root en ayant des commandes avec le sticky bit positionné en étant root sur une autre machine.
D'où ma question : les droits root sont ils universels ? Comment UNIX différencie les droits du root de la machine et les droits positionné par un autre root?
Dans le modèle unix traditionel, les supports de données amovibles, ça n'existe pas, seul root a le droit de monter des systèmes de fichiers, et il est censé s'assurer qu'il n'y a pas de bit s intempestifs dessus. De nos jours où l'on est bien obligé de laisser n'importe quel utilisateur monter un fs qu'il fournit sur un CD ou une clef USB, il y a effectivement un problème. Sous linux (j'imagine qu'il y a un truc similaire sur les autres OS), la solution retenue consiste en l'option de montage « nosuid », qui fait ignorer les bits suid et sgid par le noyau. Il faut d'ailleurs aussi l'option « nodev ». Et les systèmes permettant le montage automatique ou à la demande de l'utilisateur des fs amovibles activent ces options.
Olivier Miakinen
Il suffit de 4755, et le bit en question s'appelle setuid.
Oui.
Le bit sticky, il n'a de sens que sur les répertoires.
Il me semble que ça a un sens sur les exécutables aussi, par exemple les shells, pour les laisser en mémoire même quand personne ne les utilise (plus rapide à relancer).
Il suffit de 4755, et le bit en question s'appelle setuid.
Oui.
Le bit sticky, il n'a de sens que sur les répertoires.
Il me semble que ça a un sens sur les exécutables aussi, par exemple les
shells, pour les laisser en mémoire même quand personne ne les utilise
(plus rapide à relancer).
Il suffit de 4755, et le bit en question s'appelle setuid.
Oui.
Le bit sticky, il n'a de sens que sur les répertoires.
Il me semble que ça a un sens sur les exécutables aussi, par exemple les shells, pour les laisser en mémoire même quand personne ne les utilise (plus rapide à relancer).
lhabert
Olivier Miakinen :
Il me semble que ça a un sens sur les exécutables aussi, par exemple les shells, pour les laisser en mémoire même quand personne ne les utilise (plus rapide à relancer).
C'était le cas sur les premiers unix, mais je crois que ça fait belle lurette que plus personne n'honore ça.
Olivier Miakinen :
Il me semble que ça a un sens sur les exécutables aussi, par exemple les
shells, pour les laisser en mémoire même quand personne ne les utilise
(plus rapide à relancer).
C'était le cas sur les premiers unix, mais je crois que ça fait belle
lurette que plus personne n'honore ça.
Il me semble que ça a un sens sur les exécutables aussi, par exemple les shells, pour les laisser en mémoire même quand personne ne les utilise (plus rapide à relancer).
C'était le cas sur les premiers unix, mais je crois que ça fait belle lurette que plus personne n'honore ça.
Eric Levenez
Le 26/02/07 14:43, dans <eruo5b$1mif$, « Luc Habert » a écrit :
Olivier Miakinen :
Il me semble que ça a un sens sur les exécutables aussi, par exemple les shells, pour les laisser en mémoire même quand personne ne les utilise (plus rapide à relancer).
C'était le cas sur les premiers unix, mais je crois que ça fait belle lurette que plus personne n'honore ça.
Oui, ou plus exactement le vieux code reste en mémoire d'office grâce à la gestion de la mémoire virtuelle. Sur Mac OS X, cela remplit en partie la zone "inactive" de la RAM (que certains aimeraient voir passer en zone "libre").
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 26/02/07 14:43, dans <eruo5b$1mif$1@nef.ens.fr>, « Luc Habert »
<lhabert@clipper.ens.fr> a écrit :
Olivier Miakinen :
Il me semble que ça a un sens sur les exécutables aussi, par exemple les
shells, pour les laisser en mémoire même quand personne ne les utilise
(plus rapide à relancer).
C'était le cas sur les premiers unix, mais je crois que ça fait belle
lurette que plus personne n'honore ça.
Oui, ou plus exactement le vieux code reste en mémoire d'office grâce à la
gestion de la mémoire virtuelle. Sur Mac OS X, cela remplit en partie la
zone "inactive" de la RAM (que certains aimeraient voir passer en zone
"libre").
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 26/02/07 14:43, dans <eruo5b$1mif$, « Luc Habert » a écrit :
Olivier Miakinen :
Il me semble que ça a un sens sur les exécutables aussi, par exemple les shells, pour les laisser en mémoire même quand personne ne les utilise (plus rapide à relancer).
C'était le cas sur les premiers unix, mais je crois que ça fait belle lurette que plus personne n'honore ça.
Oui, ou plus exactement le vieux code reste en mémoire d'office grâce à la gestion de la mémoire virtuelle. Sur Mac OS X, cela remplit en partie la zone "inactive" de la RAM (que certains aimeraient voir passer en zone "libre").
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Olivier Miakinen
Le 26/02/2007 18:58, Eric Levenez renchérissait sur Luc Habert :
Il me semble que ça a un sens sur les exécutables aussi, par exemple les shells, pour les laisser en mémoire même quand personne ne les utilise (plus rapide à relancer).
C'était le cas sur les premiers unix, mais je crois que ça fait belle lurette que plus personne n'honore ça.
Oui, ou plus exactement le vieux code reste en mémoire d'office grâce à la gestion de la mémoire virtuelle. Sur Mac OS X, cela remplit en partie la zone "inactive" de la RAM (que certains aimeraient voir passer en zone "libre").
Merci à vous deux, je ne savais pas tout cela.
Le 26/02/2007 18:58, Eric Levenez renchérissait sur Luc Habert :
Il me semble que ça a un sens sur les exécutables aussi, par exemple les
shells, pour les laisser en mémoire même quand personne ne les utilise
(plus rapide à relancer).
C'était le cas sur les premiers unix, mais je crois que ça fait belle
lurette que plus personne n'honore ça.
Oui, ou plus exactement le vieux code reste en mémoire d'office grâce à la
gestion de la mémoire virtuelle. Sur Mac OS X, cela remplit en partie la
zone "inactive" de la RAM (que certains aimeraient voir passer en zone
"libre").
Le 26/02/2007 18:58, Eric Levenez renchérissait sur Luc Habert :
Il me semble que ça a un sens sur les exécutables aussi, par exemple les shells, pour les laisser en mémoire même quand personne ne les utilise (plus rapide à relancer).
C'était le cas sur les premiers unix, mais je crois que ça fait belle lurette que plus personne n'honore ça.
Oui, ou plus exactement le vieux code reste en mémoire d'office grâce à la gestion de la mémoire virtuelle. Sur Mac OS X, cela remplit en partie la zone "inactive" de la RAM (que certains aimeraient voir passer en zone "libre").
Merci à vous deux, je ne savais pas tout cela.
Stephane Dupille
Oui, ou plus exactement le vieux code reste en mémoire d'office grâce à la gestion de la mémoire virtuelle. Sur Mac OS X, cela remplit en partie la zone "inactive" de la RAM (que certains aimeraient voir passer en zone "libre").
C'est encore utilisé le sticky-bit sur les exécutables ? Parce que bon, le système est censé se démerder tout seul pour gérer ça lui-même.
Oui, ou plus exactement le vieux code reste en mémoire d'office grâce à la
gestion de la mémoire virtuelle. Sur Mac OS X, cela remplit en partie la
zone "inactive" de la RAM (que certains aimeraient voir passer en zone
"libre").
C'est encore utilisé le sticky-bit sur les exécutables ? Parce que
bon, le système est censé se démerder tout seul pour gérer ça
lui-même.
Oui, ou plus exactement le vieux code reste en mémoire d'office grâce à la gestion de la mémoire virtuelle. Sur Mac OS X, cela remplit en partie la zone "inactive" de la RAM (que certains aimeraient voir passer en zone "libre").
C'est encore utilisé le sticky-bit sur les exécutables ? Parce que bon, le système est censé se démerder tout seul pour gérer ça lui-même.
lhabert
Stephane Dupille :
Parce que bon, le système est censé se démerder tout seul pour gérer ça lui-même.
Oui, c'est ce que moi et Eric venont de dire...
Stephane Dupille :
Parce que bon, le système est censé se démerder tout seul pour gérer ça
lui-même.
Parce que bon, le système est censé se démerder tout seul pour gérer ça lui-même.
Oui, c'est ce que moi et Eric venont de dire...
Olivier Miakinen
Oui, ou plus exactement le vieux code reste en mémoire d'office grâce à la gestion de la mémoire virtuelle. Sur Mac OS X, cela remplit en partie la zone "inactive" de la RAM (que certains aimeraient voir passer en zone "libre").
C'est encore utilisé le sticky-bit sur les exécutables ? Parce que bon, le système est censé se démerder tout seul pour gérer ça lui-même.
C'est exactement ce qu'il disait... en tout cas c'est ce que j'en ai compris.
Oui, ou plus exactement le vieux code reste en mémoire d'office grâce à la
gestion de la mémoire virtuelle. Sur Mac OS X, cela remplit en partie la
zone "inactive" de la RAM (que certains aimeraient voir passer en zone
"libre").
C'est encore utilisé le sticky-bit sur les exécutables ? Parce que
bon, le système est censé se démerder tout seul pour gérer ça
lui-même.
C'est exactement ce qu'il disait... en tout cas c'est ce que j'en ai
compris.
Oui, ou plus exactement le vieux code reste en mémoire d'office grâce à la gestion de la mémoire virtuelle. Sur Mac OS X, cela remplit en partie la zone "inactive" de la RAM (que certains aimeraient voir passer en zone "libre").
C'est encore utilisé le sticky-bit sur les exécutables ? Parce que bon, le système est censé se démerder tout seul pour gérer ça lui-même.
C'est exactement ce qu'il disait... en tout cas c'est ce que j'en ai compris.
Eric Levenez
Le 26/02/07 19:33, dans <45e327cb$, « Olivier Miakinen » <om+ a écrit :
Oui, ou plus exactement le vieux code reste en mémoire d'office grâce à la gestion de la mémoire virtuelle. Sur Mac OS X, cela remplit en partie la zone "inactive" de la RAM (que certains aimeraient voir passer en zone "libre").
C'est encore utilisé le sticky-bit sur les exécutables ? Parce que bon, le système est censé se démerder tout seul pour gérer ça lui-même.
C'est exactement ce qu'il disait... en tout cas c'est ce que j'en ai compris.
Tu as bien compris.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 26/02/07 19:33, dans <45e327cb$1@neottia.net>, « Olivier Miakinen »
<om+news@miakinen.net> a écrit :
Oui, ou plus exactement le vieux code reste en mémoire d'office grâce à la
gestion de la mémoire virtuelle. Sur Mac OS X, cela remplit en partie la
zone "inactive" de la RAM (que certains aimeraient voir passer en zone
"libre").
C'est encore utilisé le sticky-bit sur les exécutables ? Parce que
bon, le système est censé se démerder tout seul pour gérer ça
lui-même.
C'est exactement ce qu'il disait... en tout cas c'est ce que j'en ai
compris.
Tu as bien compris.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 26/02/07 19:33, dans <45e327cb$, « Olivier Miakinen » <om+ a écrit :
Oui, ou plus exactement le vieux code reste en mémoire d'office grâce à la gestion de la mémoire virtuelle. Sur Mac OS X, cela remplit en partie la zone "inactive" de la RAM (que certains aimeraient voir passer en zone "libre").
C'est encore utilisé le sticky-bit sur les exécutables ? Parce que bon, le système est censé se démerder tout seul pour gérer ça lui-même.
C'est exactement ce qu'il disait... en tout cas c'est ce que j'en ai compris.
Tu as bien compris.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
