Site Télérama

Éric Lévénez

17/04/2004 à 12:31

Le 17/04/04 9:42, dans <1gcdwnb.bm8cex1d4r8fuN%,
« Pierre-Olivier TAUBATY » a écrit :

c'est un truc que je n'ai jamais compris. Si un utilisateur veut
utiliser le compte root, il lui faut l'activer et lui donner un mot de
passe.

Pour comprendre ce qu'il se passe, il faut comprendre le fonctionnement du
bit s sous unix.

Chaque utilisateur a 2 numéros, le uid, user id, et le gid, le group id. Le
uid est le plus important. Par exemple root a le numéro 0. Actuellement,
j'ai le numéro 501.

Quand je lance un programme, celui-ci s'exécute avec mes privilèges, donc
comme utilisateur 501.

Mais quand on regarde un programme comme sudo :

HAL3:~ eric$ ll /usr/bin/sudo
-r-s--x--x 1 root wheel 96540 15 Mar 23:14 /usr/bin/sudo

On voit qu'il a un bit s et non x.

Cela veut dire que quand je le lance, il ne s'exécute pas avec mes
privilèges, mais avec les siens, soit le uid du fichier, et dans ce cas,
c'est root. Ainsi même en étant simple utilisateur, le sudo que je lance
marche comme si j'étais root.

Les commandes du types sudo qui ont le bit s positionné, sont très très
surveillées. Elles permettent souvent de passer sous root sans aucun mot de
passe nécessaire. Alors pour ne pas faire n'importe quoi ces commandes
vérifient elles-même si elles peuvent ou non s'exécuter. Ainsi sudo utilise
un fichier de configuration /etc/sudoers pour voir si l'utilisateur qui le
lance est autorisé ou non à exécuter les commandes demandées.

Exemple de commandes avec le bit s :

sudo find / -perm +6000 -ls

Je ne l'ai jamais fait, suivant en cela les conseils des unixiens barbus
de ce forum ;-).

Le compte root n'est pas nécessaire sous Mac OS X.

Par contre le fait de donner le mot de passe admin peut ainsi conférer
les privilèges de root à l'installeur qui décide d'en avoir besoin ? ?

Oui.

C'est donc l'équivalent de la commande sudo ?

Oui.

Ce que je ne comprends pas c'est qu'il y avait il y a quelques temps un
problème avec l'installation de Palm Desktop, problème qui pouvait
éventuellement être résolu en se loggant en root et en procédant à
l'installation. POurquoi avait-on besoin de se logger en root alors même
que l'installeur demandait le mot de passe admin ?

Je ne sais pas pour Palm Desktop. Le mot de passe demandé (par sudo ou
l'installer), n'est qu'un test interne à l'application. L'important est le
bit s. Il permet de prendre les privilèges du propriétaire du fichier (qui
est généralement root, mais pas toujours).

Par exemple :

HAL4:/ eric$ ll
/Library/JBoss/Applications/JBossManagement.woa/JBossManagement
-rwsrwx--- 1 appserve appserve 11051 19 Sep 2003
/Library/JBoss/Applications/JBossManagement.woa/JBossManagement

Là on voit que JBossManagement a le bit s, mais le propriétaire du fichier
est appserver, mais pas root. Ainsi si on exécute ce programme il marchera
comme si l'application appserver, et non root, l'avait lancé. Cela limite
les risques.

Bon, mais en fait c'est plus compliqué que cela car les applications avec le
bit s ne prennent pas automatiquement les droits du fichier. Il faut
qu'elles utilisent une fonction particulière pour cela. Ainsi le programme
peut commencer son exécution avec les droits de celui qui les a lancés, puis
il peut temporairement passer avec des droits plus élevés (comme root), puis
il peut revenir à ses droits d'origine.

Dans le cas de Palm Desktop, en lançant l'installeur sous root, toute cette
phase s'exécute en root, et donc cela peut masquer des bugs du programmeur
qui a oublié certaines étapes dans sa gestion des privilèges.

--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.

Le 17/04/04 9:42, dans <1gcdwnb.bm8cex1d4r8fuN%pas.de.spam@chez.moi>,
« Pierre-Olivier TAUBATY » <pas.de.spam@chez.moi> a écrit :

c'est un truc que je n'ai jamais compris. Si un utilisateur veut
utiliser le compte root, il lui faut l'activer et lui donner un mot de
passe.

Pour comprendre ce qu'il se passe, il faut comprendre le fonctionnement du
bit s sous unix.

Chaque utilisateur a 2 numéros, le uid, user id, et le gid, le group id. Le
uid est le plus important. Par exemple root a le numéro 0. Actuellement,
j'ai le numéro 501.

Quand je lance un programme, celui-ci s'exécute avec mes privilèges, donc
comme utilisateur 501.

Mais quand on regarde un programme comme sudo :

HAL3:~ eric$ ll /usr/bin/sudo
-r-s--x--x 1 root wheel 96540 15 Mar 23:14 /usr/bin/sudo

On voit qu'il a un bit s et non x.

Cela veut dire que quand je le lance, il ne s'exécute pas avec mes
privilèges, mais avec les siens, soit le uid du fichier, et dans ce cas,
c'est root. Ainsi même en étant simple utilisateur, le sudo que je lance
marche comme si j'étais root.

Les commandes du types sudo qui ont le bit s positionné, sont très très
surveillées. Elles permettent souvent de passer sous root sans aucun mot de
passe nécessaire. Alors pour ne pas faire n'importe quoi ces commandes
vérifient elles-même si elles peuvent ou non s'exécuter. Ainsi sudo utilise
un fichier de configuration /etc/sudoers pour voir si l'utilisateur qui le
lance est autorisé ou non à exécuter les commandes demandées.

Exemple de commandes avec le bit s :

sudo find / -perm +6000 -ls

Je ne l'ai jamais fait, suivant en cela les conseils des unixiens barbus
de ce forum ;-).

Le compte root n'est pas nécessaire sous Mac OS X.

Par contre le fait de donner le mot de passe admin peut ainsi conférer
les privilèges de root à l'installeur qui décide d'en avoir besoin ? ?

Oui.

C'est donc l'équivalent de la commande sudo ?

Oui.

Ce que je ne comprends pas c'est qu'il y avait il y a quelques temps un
problème avec l'installation de Palm Desktop, problème qui pouvait
éventuellement être résolu en se loggant en root et en procédant à
l'installation. POurquoi avait-on besoin de se logger en root alors même
que l'installeur demandait le mot de passe admin ?

Je ne sais pas pour Palm Desktop. Le mot de passe demandé (par sudo ou
l'installer), n'est qu'un test interne à l'application. L'important est le
bit s. Il permet de prendre les privilèges du propriétaire du fichier (qui
est généralement root, mais pas toujours).

Par exemple :

HAL4:/ eric$ ll
/Library/JBoss/Applications/JBossManagement.woa/JBossManagement
-rwsrwx--- 1 appserve appserve 11051 19 Sep 2003
/Library/JBoss/Applications/JBossManagement.woa/JBossManagement

Là on voit que JBossManagement a le bit s, mais le propriétaire du fichier
est appserver, mais pas root. Ainsi si on exécute ce programme il marchera
comme si l'application appserver, et non root, l'avait lancé. Cela limite
les risques.

Bon, mais en fait c'est plus compliqué que cela car les applications avec le
bit s ne prennent pas automatiquement les droits du fichier. Il faut
qu'elles utilisent une fonction particulière pour cela. Ainsi le programme
peut commencer son exécution avec les droits de celui qui les a lancés, puis
il peut temporairement passer avec des droits plus élevés (comme root), puis
il peut revenir à ses droits d'origine.

Dans le cas de Palm Desktop, en lançant l'installeur sous root, toute cette
phase s'exécute en root, et donc cela peut masquer des bugs du programmeur
qui a oublié certaines étapes dans sa gestion des privilèges.

--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.

Vous avez filtré cet utilisateur ! Consultez son message

Le 17/04/04 9:42, dans <1gcdwnb.bm8cex1d4r8fuN%,
« Pierre-Olivier TAUBATY » a écrit :

c'est un truc que je n'ai jamais compris. Si un utilisateur veut
utiliser le compte root, il lui faut l'activer et lui donner un mot de
passe.

Pour comprendre ce qu'il se passe, il faut comprendre le fonctionnement du
bit s sous unix.

Chaque utilisateur a 2 numéros, le uid, user id, et le gid, le group id. Le
uid est le plus important. Par exemple root a le numéro 0. Actuellement,
j'ai le numéro 501.

Quand je lance un programme, celui-ci s'exécute avec mes privilèges, donc
comme utilisateur 501.

Mais quand on regarde un programme comme sudo :

HAL3:~ eric$ ll /usr/bin/sudo
-r-s--x--x 1 root wheel 96540 15 Mar 23:14 /usr/bin/sudo

On voit qu'il a un bit s et non x.

Cela veut dire que quand je le lance, il ne s'exécute pas avec mes
privilèges, mais avec les siens, soit le uid du fichier, et dans ce cas,
c'est root. Ainsi même en étant simple utilisateur, le sudo que je lance
marche comme si j'étais root.

Les commandes du types sudo qui ont le bit s positionné, sont très très
surveillées. Elles permettent souvent de passer sous root sans aucun mot de
passe nécessaire. Alors pour ne pas faire n'importe quoi ces commandes
vérifient elles-même si elles peuvent ou non s'exécuter. Ainsi sudo utilise
un fichier de configuration /etc/sudoers pour voir si l'utilisateur qui le
lance est autorisé ou non à exécuter les commandes demandées.

Exemple de commandes avec le bit s :

sudo find / -perm +6000 -ls

Je ne l'ai jamais fait, suivant en cela les conseils des unixiens barbus
de ce forum ;-).

Le compte root n'est pas nécessaire sous Mac OS X.

Par contre le fait de donner le mot de passe admin peut ainsi conférer
les privilèges de root à l'installeur qui décide d'en avoir besoin ? ?

Oui.

C'est donc l'équivalent de la commande sudo ?

Oui.

Ce que je ne comprends pas c'est qu'il y avait il y a quelques temps un
problème avec l'installation de Palm Desktop, problème qui pouvait
éventuellement être résolu en se loggant en root et en procédant à
l'installation. POurquoi avait-on besoin de se logger en root alors même
que l'installeur demandait le mot de passe admin ?

Je ne sais pas pour Palm Desktop. Le mot de passe demandé (par sudo ou
l'installer), n'est qu'un test interne à l'application. L'important est le
bit s. Il permet de prendre les privilèges du propriétaire du fichier (qui
est généralement root, mais pas toujours).

Par exemple :

HAL4:/ eric$ ll
/Library/JBoss/Applications/JBossManagement.woa/JBossManagement
-rwsrwx--- 1 appserve appserve 11051 19 Sep 2003
/Library/JBoss/Applications/JBossManagement.woa/JBossManagement

Là on voit que JBossManagement a le bit s, mais le propriétaire du fichier
est appserver, mais pas root. Ainsi si on exécute ce programme il marchera
comme si l'application appserver, et non root, l'avait lancé. Cela limite
les risques.

Bon, mais en fait c'est plus compliqué que cela car les applications avec le
bit s ne prennent pas automatiquement les droits du fichier. Il faut
qu'elles utilisent une fonction particulière pour cela. Ainsi le programme
peut commencer son exécution avec les droits de celui qui les a lancés, puis
il peut temporairement passer avec des droits plus élevés (comme root), puis
il peut revenir à ses droits d'origine.

Dans le cas de Palm Desktop, en lançant l'installeur sous root, toute cette
phase s'exécute en root, et donc cela peut masquer des bugs du programmeur
qui a oublié certaines étapes dans sa gestion des privilèges.

--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.

pas.de.spam

17/04/2004 à 13:48

Éric Lévénez wrote:

[Snip plein de choses intéressantes]

Merci bien pour ces explications.

Ce que je trouve dommage, c'est que lorsque un installeur nous demande
un mot de passe, on ne sait pas si c'est pour faire des choses en tant
qu'admin, ou en tant que root.

Je peux fort bien imaginer qu'une mise à jour système doive avoir les
pleins pouvoir (donc root).

Mais dès lors qu'il s'agit d'une autre installation, ce serait
intéressant de savoir ce qu'elle va faire de mnière claire, sans avoir
aller à trifouiller dans les packages comme certains le font
systématiquement.

Si on avait 2 messages différents selon qu'il faille entrer le mot de
passe admin, ou le mot de passe root, on pourrait être un peu plus
vigilant lors des installations.

Remarque bien qu'apparemment, je n'ai pas eu de gros soucis depuis que
je suis sous X, donc je me (te) prends peut-être un peu la tête pour pas
grand chose.

Mais bon, j'aime bien comprendre.

Ceci dit, merci encore.
--
PO.

Pour m'écrire : po(point)taubaty(arobase)wanadoo(point)fr

Éric Lévénez

17/04/2004 à 14:37

Le 17/04/04 13:48, dans <1gce8wy.9beyw1od0qwkN%,
« Pierre-Olivier TAUBATY » a écrit :

Ce que je trouve dommage, c'est que lorsque un installeur nous demande
un mot de passe, on ne sait pas si c'est pour faire des choses en tant
qu'admin, ou en tant que root.

Heu, 99,999 % des fois où un mot de passe est demandé c'est pour que
l'exécution se fasse sous root. Il n'y a pas vraiment d'utilisateur admin au
sens où tu l'entends.

Je peux fort bien imaginer qu'une mise à jour système doive avoir les
pleins pouvoir (donc root).

Oui.

Mais dès lors qu'il s'agit d'une autre installation, ce serait
intéressant de savoir ce qu'elle va faire de mnière claire, sans avoir
aller à trifouiller dans les packages comme certains le font
systématiquement.

Oui, mais là 99,999 % des utilisateurs ne comprendraient rien aux
explications. Quand on voit que déjà les développeurs, qui sont sensés
connaître cela se plantent en pagaille, alors les "simples" utilisateurs...

Si on avait 2 messages différents selon qu'il faille entrer le mot de
passe admin, ou le mot de passe root, on pourrait être un peu plus
vigilant lors des installations.

Les applis ne demandent jamais le mot de passe root car root n'est pas
activé et donc n'a pas de mot de passe. Le mot de passe demandé n'a pas
grand chose à voir avec ce qu'en fera l'application. Au lieu du mot de
passe, l'application pourrait aussi demander l'âge du capitaine ou juste
demander de cliquer sur une icône. Ce qui compte c'est que l'application, en
fonction de la réponse, va changer ou non les droits de l'exécutable pour
les faire évoluer vers root.

--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.

jperrocheau

17/04/2004 à 22:42

Pierre-Olivier TAUBATY wrote:

C'est quand même marrant ce quee tu dis parce que je viens de me battre
avec ma bécane qui était affligée d'une lenteur insupportable au
démarrage (G4 bi 1,25, 1,5Go RAM) : 2'38".

J'ai procédé au cas où à une réparation des droits et autorisations qui
n'a pas amérlioré la vitesse de démarage. J'ai ensuite procédé à la mise
à jour 10.3.3, puis, juste pour voir, une autre réparation, et bien il
ya en avait besoin. Alors qu'il s'est écoulé une dizaine de minutes
entre la précédente réparation. Hormis l'install de la 10.3.3, je
n'avais rien fait d'autre sur la machine.

Apple lui-même se prend les pieds dans ces histoires de réparations de
privilèges, avec les mises à jour. Il fait des modif dans les fichiers,
mais il ne modifie pas toujours les receipts correspondants ce qui fait
que parfois en réparant les privilèges après une mise à jour tu reviens
en arrière en ce qui concerne ces réglages.

Exemples, sur une machine en Mac OS 10.3.3 constamment mise à jour "par
dessus" depuis Mac OS 10.1.2.

Group differs on ./private/etc/authorization, should be 80, group is 0

ou

Permissions differ on ./private/var/log/install.log, should be
-rw-r--r-- , they are -rw-r-----

ou

Permissions differ on
./System/Library/Filesystems/cd9660.fs/cd9660.util, should be -rwsr-xr-x
, they are -rwxr-xr-x

qui est devenu

We are using special permissions for the file or directory
./System/Library/Filesystems/cd9660.fs/cd9660.util. New permissions are
33261

depuis je ne sais quelle mise à jour...

Le résultat dépend aussi de l'historique de tes mises à jour majeures
(Puma, Jaguar, Panther, mises à jour par dessus ou mises à jour "à côté"
ou installation ab initio).

Cela dit il n'y a pas d'erreur fatale que des trucs un peu agaçant.

--
Jacques PERROCHEAU
______________________________________________________________
e-mail: mailto:

pas.de.spam

19/04/2004 à 12:14

Patrick C wrote:

Pierre-Olivier TAUBATY wrote:

Si on avait 2 messages différents selon qu'il faille entrer le mot de
passe admin, ou le mot de passe root, on pourrait être un peu plus
vigilant lors des installations.

Lors de la demande du mot de passe pour une installation, tu peux
déplier le menu pour avoir l'info du lieu où l'appli veut accéder avec
ces droits.

je l'ignorais totalement. Merci beaucoup du renseignement. La prochaine
fois, j'irais voir par curiosité. Par curiosité seulement, car je
suppose que 90 % (au moins) des dossiers concernés me seront inconnus,
mais au moins je pourrais voir si cela va loin dans les entrailles de
l'OS.
--
PO.

Pour m'écrire : po(point)taubaty(arobase)wanadoo(point)fr

Site Télérama

5 réponses

Veuillez sélectionner un problème