Le modèle UNIX a des variables d'environnement attachées aux processus et qui s'hérite de père en fils, mais non l'inverse. Un fils ne peut influencer le fils d'un autre processus. Cette indépendance est fondamentale pour la stabilité et la simplicité de l'ensemble et c'est pourquoi je déteste gconf. Lorsque je modifie un paramêtre important, je préfère relancer les applications. En plus, cela n'arrive pas souvent.
Sous Windows, les variables d'environnement sont globales par utilisateurs, voir pour le système. D'ailleurs, tout cela est stockée dans la base de registre qui est un énorme système de variable globale. C'est exactement ce que l'on déconseille à tout programmeur.
Altering the environment variables of a child process during process creation is the only way one process can directly change the environment variables of another process. A process can never directly change the environment variables of another process that is not a child of that process.
Sous UNIX, root avait (c'est en train de changer) tous les pouvoirs, ce n'est pas le cas sous Windows. Sous Windows, le root ne peut pas faire un chown...
Sous Windows, avec le système kerberos, on n'a pas de système équivalent a su, sudo... Bref de bit suid. Bilan, c'est une usine à gaz et une vrai daube lorsqu'on veut lancer en batch des choses sous un autre compte.
Equivalent de su : runas.exe
sudo il n'y a pas d'equivalent par defaut, mais ca existe separament
Et tu m'expliqueras le rapport entre su et des services tournant sous root...
Je ne parle pas du compte SYSTEM qui existe sans exister et dont les scripts .bat ont un comportement parfois plus qu'étrange...
Perso, et au vu de ta meconnaissance du systeme, je pencherai pour une autre explication.
Surtout qu'encore une fois, les ACL de Windows sont une telle usine à gaz qu'il y a tant de réglage possible que je n'ai pas encore rencontré une seule personne capable de faire des réglages beaucoup plus pointus que s'il y avait 4 ou 5 réglages possibles, comme sous UNIX ! La encore Windows à tuer les ACL avec leur complexité.
Que tu ne les comprennes pas ne veut pas dire que personne ne les comprend. Il suffit de comprendre que les ACE sont executees dans l'ordre et que l'evaluation stoppe a la premier entree qui match pour comprendre comment ca fonctionne ,ca n'a rien de sorcier.
D'ailleurs, lorsqu'on n'est pas en domaine, Microsoft a préféré les cacher aux utilisateurs, c'est tout dire.
Effectivement, ca en dit long sur la finition de Windows pour le desktop, car ta grand-mere (et la mienne) n'ont aucune idee de ce qu'est une permission.
Au passage, tu noteras que Windows XP Pro n'a pas cette configuration, c'est uniquement la version Home.
Bref, je te conseille de lire le bouquin "Windows Internals" ...
Re: SMACK
Le modèle UNIX a des variables d'environnement attachées aux processus et qui s'hérite de père en fils, mais non l'inverse. Un fils ne peut influencer le fils d'un autre processus. Cette indépendance est fondamentale pour la stabilité et la simplicité de l'ensemble et c'est pourquoi je déteste gconf. Lorsque je modifie un paramêtre important, je préfère relancer les applications. En plus, cela n'arrive pas souvent.
Sous Windows, les variables d'environnement sont globales par utilisateurs, voir pour le système. D'ailleurs, tout cela est stockée dans la base de registre qui est un énorme système de variable globale. C'est exactement ce que l'on déconseille à tout programmeur.
Tu as tout faux. http://msdn2.microsoft.com/en-us/library/ms682009.aspx
Altering the environment variables of a child process during process creation is the only way one process can directly change the environment variables of another process. A process can never directly change the environment variables of another process that is not a child of that process.
Sous UNIX, root avait (c'est en train de changer) tous les pouvoirs, ce n'est pas le cas sous Windows. Sous Windows, le root ne peut pas faire un chown...
Faux encore, cf. http://support.microsoft.com/kb/308421
Sous Windows, avec le système kerberos, on n'a pas de système équivalent a su, sudo... Bref de bit suid. Bilan, c'est une usine à gaz et une vrai daube lorsqu'on veut lancer en batch des choses sous un autre compte.
Equivalent de su : runas.exe
sudo il n'y a pas d'equivalent par defaut, mais ca existe separament
Et tu m'expliqueras le rapport entre su et des services tournant sous root...
Je ne parle pas du compte SYSTEM qui existe sans exister et dont les scripts .bat ont un comportement parfois plus qu'étrange...
Perso, et au vu de ta meconnaissance du systeme, je pencherai pour une autre explication.
Surtout qu'encore une fois, les ACL de Windows sont une telle usine à gaz qu'il y a tant de réglage possible que je n'ai pas encore rencontré une seule personne capable de faire des réglages beaucoup plus pointus que s'il y avait 4 ou 5 réglages possibles, comme sous UNIX ! La encore Windows à tuer les ACL avec leur complexité.
Que tu ne les comprennes pas ne veut pas dire que personne ne les comprend. Il suffit de comprendre que les ACE sont executees dans l'ordre et que l'evaluation stoppe a la premier entree qui match pour comprendre comment ca fonctionne ,ca n'a rien de sorcier.
D'ailleurs, lorsqu'on n'est pas en domaine, Microsoft a préféré les cacher aux utilisateurs, c'est tout dire.
Effectivement, ca en dit long sur la finition de Windows pour le desktop, car ta grand-mere (et la mienne) n'ont aucune idee de ce qu'est une permission.
Au passage, tu noteras que Windows XP Pro n'a pas cette configuration, c'est uniquement la version Home.
Bref, je te conseille de lire le bouquin "Windows Internals" ...
[ Répondre ]