"Bruno GUERPILLON" a écrit dans le message de news: | Bonjour,
Bonjour,
| Je voudrais utiliser des variables mais j'ai quelques misères. Le | script en lui-même : | | ================================================ | $COMP1 = read-host "Nom de l'ordinateur : (si local, faites <Entrée>)" | IF ($COMP1) { $opt = "-computer $COMP1" } | Get-WmiObject -class WIN32_service $opt | format-table -Property Name, | Displayname -autosize -wrap | ================================================ | | Mais cela ne fonctionne pas, l'erreur : | | ================================================ | Get-WmiObject : Demande non valide | Au niveau de F:_Systeme_Adminpowershellgetservice.ps1 : 3 | Caractère : 14 + Get-WmiObject <<<< -class WIN32_service $opt | | format-table -Property Name, Displayname -autosize -wrap | ================================================ | | Le problème que j'ai c'est que la subsitution de $opt ne se fait pas. | Une idée ? | | Amicalement, | | Bruno
Il suffit d'exécuter la commande PowerShell disponible sous forme de chaîne via la commandlet Invoke-Expression : Invoke-Expression "Get-WMIObject -class Win32_Service $opt | format-table"
"Bruno GUERPILLON" <bruno.guerpillon@free.fr> a écrit dans le message
de news:F5CA18AC-4A36-4E27-B26B-D484114F3FD6@microsoft.com
| Bonjour,
Bonjour,
| Je voudrais utiliser des variables mais j'ai quelques misères. Le
| script en lui-même :
|
| ================================================ | $COMP1 = read-host "Nom de l'ordinateur : (si local, faites <Entrée>)"
| IF ($COMP1) { $opt = "-computer $COMP1" }
| Get-WmiObject -class WIN32_service $opt | format-table -Property Name,
| Displayname -autosize -wrap
| ================================================ |
| Mais cela ne fonctionne pas, l'erreur :
|
| ================================================ | Get-WmiObject : Demande non valide
| Au niveau de F:_Systeme_Adminpowershellgetservice.ps1 : 3
| Caractère : 14 + Get-WmiObject <<<< -class WIN32_service $opt |
| format-table -Property Name, Displayname -autosize -wrap
| ================================================ |
| Le problème que j'ai c'est que la subsitution de $opt ne se fait pas.
| Une idée ?
|
| Amicalement,
|
| Bruno
Il suffit d'exécuter la commande PowerShell disponible sous forme de
chaîne via la commandlet Invoke-Expression :
Invoke-Expression "Get-WMIObject -class Win32_Service $opt |
format-table"
"Bruno GUERPILLON" a écrit dans le message de news: | Bonjour,
Bonjour,
| Je voudrais utiliser des variables mais j'ai quelques misères. Le | script en lui-même : | | ================================================ | $COMP1 = read-host "Nom de l'ordinateur : (si local, faites <Entrée>)" | IF ($COMP1) { $opt = "-computer $COMP1" } | Get-WmiObject -class WIN32_service $opt | format-table -Property Name, | Displayname -autosize -wrap | ================================================ | | Mais cela ne fonctionne pas, l'erreur : | | ================================================ | Get-WmiObject : Demande non valide | Au niveau de F:_Systeme_Adminpowershellgetservice.ps1 : 3 | Caractère : 14 + Get-WmiObject <<<< -class WIN32_service $opt | | format-table -Property Name, Displayname -autosize -wrap | ================================================ | | Le problème que j'ai c'est que la subsitution de $opt ne se fait pas. | Une idée ? | | Amicalement, | | Bruno
Il suffit d'exécuter la commande PowerShell disponible sous forme de chaîne via la commandlet Invoke-Expression : Invoke-Expression "Get-WMIObject -class Win32_Service $opt | format-table"
"Gilles LAURENT" a écrit dans le message de news:%
"Bruno GUERPILLON" a écrit dans le message de news: | Bonjour,
Bonjour,
| Je voudrais utiliser des variables mais j'ai quelques misères. Le | script en lui-même : | | ================================================ > | $COMP1 = read-host "Nom de l'ordinateur : (si local, faites <Entrée>)" | IF ($COMP1) { $opt = "-computer $COMP1" } | Get-WmiObject -class WIN32_service $opt | format-table -Property Name, | Displayname -autosize -wrap | ================================================ > | | Mais cela ne fonctionne pas, l'erreur : | | ================================================ > | Get-WmiObject : Demande non valide | Au niveau de F:_Systeme_Adminpowershellgetservice.ps1 : 3 | Caractère : 14 + Get-WmiObject <<<< -class WIN32_service $opt | | format-table -Property Name, Displayname -autosize -wrap | ================================================ > | | Le problème que j'ai c'est que la subsitution de $opt ne se fait pas. | Une idée ? | | Amicalement, | | Bruno
Il suffit d'exécuter la commande PowerShell disponible sous forme de chaîne via la commandlet Invoke-Expression : Invoke-Expression "Get-WMIObject -class Win32_Service $opt | format-table"
"Gilles LAURENT" <glsft@free.fr> a écrit dans le message de
news:%2305oHyjjHHA.4896@TK2MSFTNGP02.phx.gbl...
"Bruno GUERPILLON" <bruno.guerpillon@free.fr> a écrit dans le message
de news:F5CA18AC-4A36-4E27-B26B-D484114F3FD6@microsoft.com
| Bonjour,
Bonjour,
| Je voudrais utiliser des variables mais j'ai quelques misères. Le
| script en lui-même :
|
| ================================================ > | $COMP1 = read-host "Nom de l'ordinateur : (si local, faites <Entrée>)"
| IF ($COMP1) { $opt = "-computer $COMP1" }
| Get-WmiObject -class WIN32_service $opt | format-table -Property Name,
| Displayname -autosize -wrap
| ================================================ > |
| Mais cela ne fonctionne pas, l'erreur :
|
| ================================================ > | Get-WmiObject : Demande non valide
| Au niveau de F:_Systeme_Adminpowershellgetservice.ps1 : 3
| Caractère : 14 + Get-WmiObject <<<< -class WIN32_service $opt |
| format-table -Property Name, Displayname -autosize -wrap
| ================================================ > |
| Le problème que j'ai c'est que la subsitution de $opt ne se fait pas.
| Une idée ?
|
| Amicalement,
|
| Bruno
Il suffit d'exécuter la commande PowerShell disponible sous forme de
chaîne via la commandlet Invoke-Expression :
Invoke-Expression "Get-WMIObject -class Win32_Service $opt |
format-table"
"Gilles LAURENT" a écrit dans le message de news:%
"Bruno GUERPILLON" a écrit dans le message de news: | Bonjour,
Bonjour,
| Je voudrais utiliser des variables mais j'ai quelques misères. Le | script en lui-même : | | ================================================ > | $COMP1 = read-host "Nom de l'ordinateur : (si local, faites <Entrée>)" | IF ($COMP1) { $opt = "-computer $COMP1" } | Get-WmiObject -class WIN32_service $opt | format-table -Property Name, | Displayname -autosize -wrap | ================================================ > | | Mais cela ne fonctionne pas, l'erreur : | | ================================================ > | Get-WmiObject : Demande non valide | Au niveau de F:_Systeme_Adminpowershellgetservice.ps1 : 3 | Caractère : 14 + Get-WmiObject <<<< -class WIN32_service $opt | | format-table -Property Name, Displayname -autosize -wrap | ================================================ > | | Le problème que j'ai c'est que la subsitution de $opt ne se fait pas. | Une idée ? | | Amicalement, | | Bruno
Il suffit d'exécuter la commande PowerShell disponible sous forme de chaîne via la commandlet Invoke-Expression : Invoke-Expression "Get-WMIObject -class Win32_Service $opt | format-table"
Invoke-Expression sera TRES intéressant, le jour où on aura un PowerShell comme serveur COM. Cela permettra de faire (presque) n'importe quoi, depuis (presque) n'importe quels langages ou applications.
@+
MCI
Re !
Invoke-Expression sera TRES intéressant, le jour où on aura un PowerShell
comme serveur COM.
Cela permettra de faire (presque) n'importe quoi, depuis (presque) n'importe
quels langages ou applications.
Invoke-Expression sera TRES intéressant, le jour où on aura un PowerShell comme serveur COM. Cela permettra de faire (presque) n'importe quoi, depuis (presque) n'importe quels langages ou applications.
@+
MCI
Jacques Barathon [MS]
"Bruno GUERPILLON" wrote in message news:
Bonjour Gilles
Merci pour m'avoir eclairé sur Invoke-Expression.
Au final mon script (de départ) ressemble à ceci :
Je profite d'une brève éclaircie dans ces quelques semaines un peu mouvementées pour apporter un bémol à cette solution à priori très tentante, et à fortiori efficace. La commandelette invoke-expression est à manipuler avec beaucoup de précautions dans un contexte comme celui-ci où une partie du contenu est déterminée par la saisie de l'utilisateur. On est alors dans un magnifique exemple d'injection de code. Imaginez que l'utilisateur, ou très taquin ou un brin maladroit, saisisse le texte suivant lorsque le script le lui demande le nom de l'ordinateur:
| %{$_.StopService()}
Le résultat (non testé mais à peu près garanti pur beurre) est un arrêt immédiat de tous les services du poste. Et ceci n'est évidemment qu'un exemple, "the sky is your limit"...
Il vaut donc mieux réserver invoke-expression à des contextes où le contenu de la commande à exécuter peut être protégé soit par la fourniture des éléments de texte uniquement en interne depuis le script, soit par un contrôle très strict du texte apporté par des sources extérieures.
Dans ce cas précis, la solution de Michel (lecture de $comp1, utilisation de $comp1 comme valeur passée au paramètre -computername) est de TRES LOIN la plus sûre.
Jacques
"Bruno GUERPILLON" <bruno.guerpillon@free.fr> wrote in message
news:eKuNHWkjHHA.4768@TK2MSFTNGP05.phx.gbl...
Bonjour Gilles
Merci pour m'avoir eclairé sur Invoke-Expression.
Au final mon script (de départ) ressemble à ceci :
Je profite d'une brève éclaircie dans ces quelques semaines un peu
mouvementées pour apporter un bémol à cette solution à priori très tentante,
et à fortiori efficace. La commandelette invoke-expression est à manipuler
avec beaucoup de précautions dans un contexte comme celui-ci où une partie
du contenu est déterminée par la saisie de l'utilisateur. On est alors dans
un magnifique exemple d'injection de code. Imaginez que l'utilisateur, ou
très taquin ou un brin maladroit, saisisse le texte suivant lorsque le
script le lui demande le nom de l'ordinateur:
| %{$_.StopService()}
Le résultat (non testé mais à peu près garanti pur beurre) est un arrêt
immédiat de tous les services du poste. Et ceci n'est évidemment qu'un
exemple, "the sky is your limit"...
Il vaut donc mieux réserver invoke-expression à des contextes où le contenu
de la commande à exécuter peut être protégé soit par la fourniture des
éléments de texte uniquement en interne depuis le script, soit par un
contrôle très strict du texte apporté par des sources extérieures.
Dans ce cas précis, la solution de Michel (lecture de $comp1, utilisation de
$comp1 comme valeur passée au paramètre -computername) est de TRES LOIN la
plus sûre.
Je profite d'une brève éclaircie dans ces quelques semaines un peu mouvementées pour apporter un bémol à cette solution à priori très tentante, et à fortiori efficace. La commandelette invoke-expression est à manipuler avec beaucoup de précautions dans un contexte comme celui-ci où une partie du contenu est déterminée par la saisie de l'utilisateur. On est alors dans un magnifique exemple d'injection de code. Imaginez que l'utilisateur, ou très taquin ou un brin maladroit, saisisse le texte suivant lorsque le script le lui demande le nom de l'ordinateur:
| %{$_.StopService()}
Le résultat (non testé mais à peu près garanti pur beurre) est un arrêt immédiat de tous les services du poste. Et ceci n'est évidemment qu'un exemple, "the sky is your limit"...
Il vaut donc mieux réserver invoke-expression à des contextes où le contenu de la commande à exécuter peut être protégé soit par la fourniture des éléments de texte uniquement en interne depuis le script, soit par un contrôle très strict du texte apporté par des sources extérieures.
Dans ce cas précis, la solution de Michel (lecture de $comp1, utilisation de $comp1 comme valeur passée au paramètre -computername) est de TRES LOIN la plus sûre.
Jacques
Gilles LAURENT
"Jacques Barathon [MS]" a écrit dans le message de news:
| Je profite d'une brève éclaircie dans ces quelques semaines un peu | mouvementées pour apporter un bémol à cette solution à priori très | tentante, et à fortiori efficace. La commandelette invoke-expression | est à manipuler avec beaucoup de précautions dans un contexte comme | celui-ci où une partie du contenu est déterminée par la saisie de | l'utilisateur. On est alors dans un magnifique exemple d'injection de | code. Imaginez que l'utilisateur, ou très taquin ou un brin | maladroit, saisisse le texte suivant lorsque le script le lui demande | le nom de l'ordinateur: | || %{$_.StopService()} | | Le résultat (non testé mais à peu près garanti pur beurre) est un | arrêt immédiat de tous les services du poste. Et ceci n'est | évidemment qu'un exemple, "the sky is your limit"... [...]
En effet, je vous l'accorde, il peut y avoir un risque d'injection de code malveillant. Cependant, le risque est présent uniquement si le script s'exécute sous une autorité différente de celle de l'utilisateur, ce qui, je pense, est rarement le cas d'un script Powershell d'administration. Ci-dessous un lien vers un article fort intéressant : http://blogs.msdn.com/powershell/archive/2006/11/23/protecting-against-malicious-code-injection.aspx
"Code injection attacks become attacks once they cross a trust boundary. If they don't cross a trust boundary, they are just a complicated and buggy way of doing what a user could already do." - Lee Holmes - PowerShell Team
Quoi qu'il en soit, la commandlet Invoke-Expression est à manipuler avec précaution, tout comme Execute et ExecuteGlobal en VBScript d'ailleur ;-)
"Jacques Barathon [MS]" <jbaratho@online.microsoft.com> a écrit dans le
message de news:eN8RvRjkHHA.4672@TK2MSFTNGP05.phx.gbl
| Je profite d'une brève éclaircie dans ces quelques semaines un peu
| mouvementées pour apporter un bémol à cette solution à priori très
| tentante, et à fortiori efficace. La commandelette invoke-expression
| est à manipuler avec beaucoup de précautions dans un contexte comme
| celui-ci où une partie du contenu est déterminée par la saisie de
| l'utilisateur. On est alors dans un magnifique exemple d'injection de
| code. Imaginez que l'utilisateur, ou très taquin ou un brin
| maladroit, saisisse le texte suivant lorsque le script le lui demande
| le nom de l'ordinateur:
|
|| %{$_.StopService()}
|
| Le résultat (non testé mais à peu près garanti pur beurre) est un
| arrêt immédiat de tous les services du poste. Et ceci n'est
| évidemment qu'un exemple, "the sky is your limit"...
[...]
En effet, je vous l'accorde, il peut y avoir un risque d'injection de
code malveillant. Cependant, le risque est présent uniquement si le
script s'exécute sous une autorité différente de celle de l'utilisateur,
ce qui, je pense, est rarement le cas d'un script Powershell
d'administration. Ci-dessous un lien vers un article fort intéressant :
http://blogs.msdn.com/powershell/archive/2006/11/23/protecting-against-malicious-code-injection.aspx
"Code injection attacks become attacks once they cross a trust boundary.
If they don't cross a trust boundary, they are just a complicated and
buggy way of doing what a user could already do." - Lee Holmes -
PowerShell Team
Quoi qu'il en soit, la commandlet Invoke-Expression est à manipuler avec
précaution, tout comme Execute et ExecuteGlobal en VBScript d'ailleur
;-)
"Jacques Barathon [MS]" a écrit dans le message de news:
| Je profite d'une brève éclaircie dans ces quelques semaines un peu | mouvementées pour apporter un bémol à cette solution à priori très | tentante, et à fortiori efficace. La commandelette invoke-expression | est à manipuler avec beaucoup de précautions dans un contexte comme | celui-ci où une partie du contenu est déterminée par la saisie de | l'utilisateur. On est alors dans un magnifique exemple d'injection de | code. Imaginez que l'utilisateur, ou très taquin ou un brin | maladroit, saisisse le texte suivant lorsque le script le lui demande | le nom de l'ordinateur: | || %{$_.StopService()} | | Le résultat (non testé mais à peu près garanti pur beurre) est un | arrêt immédiat de tous les services du poste. Et ceci n'est | évidemment qu'un exemple, "the sky is your limit"... [...]
En effet, je vous l'accorde, il peut y avoir un risque d'injection de code malveillant. Cependant, le risque est présent uniquement si le script s'exécute sous une autorité différente de celle de l'utilisateur, ce qui, je pense, est rarement le cas d'un script Powershell d'administration. Ci-dessous un lien vers un article fort intéressant : http://blogs.msdn.com/powershell/archive/2006/11/23/protecting-against-malicious-code-injection.aspx
"Code injection attacks become attacks once they cross a trust boundary. If they don't cross a trust boundary, they are just a complicated and buggy way of doing what a user could already do." - Lee Holmes - PowerShell Team
Quoi qu'il en soit, la commandlet Invoke-Expression est à manipuler avec précaution, tout comme Execute et ExecuteGlobal en VBScript d'ailleur ;-)
"Jacques Barathon [MS]" a écrit dans le message de news: <...>
En effet, je vous l'accorde, il peut y avoir un risque d'injection de code malveillant. Cependant, le risque est présent uniquement si le script s'exécute sous une autorité différente de celle de l'utilisateur, ce qui, je pense, est rarement le cas d'un script Powershell d'administration. Ci-dessous un lien vers un article fort intéressant : http://blogs.msdn.com/powershell/archive/2006/11/23/protecting-against-malicious-code-injection.aspx
"Code injection attacks become attacks once they cross a trust boundary. If they don't cross a trust boundary, they are just a complicated and buggy way of doing what a user could already do." - Lee Holmes - PowerShell Team
L'avis de Lee est tout à fait juste, mais il parle "d'attaque". Je n'allais pas jusque là. Evidemment, dans mon exemple j'ai un peu trop forcé le trait pour représenter une faute de frappe ou une simple confusion dans ce qui est demandé, mais je voulais attirer votre attention sur une source importante de comportements imprévisibles voire destructeurs en cas d'erreur.
Surtout que dans ce cas précis, l'utilisation d'invoke-expression est totalement inutile, l'objectif initial de Bruno étant simplement de passer une valeur variable à un paramètre qui, lui, est toujours le même. On est donc assez loin des cas où on a besoin de construire une expression à la volée. Et finalement, pourquoi faire compliqué et risqué quand on peut faire simple et sûr?
Quoi qu'il en soit, la commandlet Invoke-Expression est à manipuler avec précaution, tout comme Execute et ExecuteGlobal en VBScript d'ailleur ;-)
Tout à fait Gilles. :-)
Jacques
"Gilles LAURENT" <glsft@free.fr> wrote in message
news:OBG8QRlkHHA.3996@TK2MSFTNGP06.phx.gbl...
"Jacques Barathon [MS]" <jbaratho@online.microsoft.com> a écrit dans le
message de news:eN8RvRjkHHA.4672@TK2MSFTNGP05.phx.gbl
<...>
En effet, je vous l'accorde, il peut y avoir un risque d'injection de
code malveillant. Cependant, le risque est présent uniquement si le
script s'exécute sous une autorité différente de celle de l'utilisateur,
ce qui, je pense, est rarement le cas d'un script Powershell
d'administration. Ci-dessous un lien vers un article fort intéressant :
http://blogs.msdn.com/powershell/archive/2006/11/23/protecting-against-malicious-code-injection.aspx
"Code injection attacks become attacks once they cross a trust boundary.
If they don't cross a trust boundary, they are just a complicated and
buggy way of doing what a user could already do." - Lee Holmes -
PowerShell Team
L'avis de Lee est tout à fait juste, mais il parle "d'attaque". Je n'allais
pas jusque là. Evidemment, dans mon exemple j'ai un peu trop forcé le trait
pour représenter une faute de frappe ou une simple confusion dans ce qui est
demandé, mais je voulais attirer votre attention sur une source importante
de comportements imprévisibles voire destructeurs en cas d'erreur.
Surtout que dans ce cas précis, l'utilisation d'invoke-expression est
totalement inutile, l'objectif initial de Bruno étant simplement de passer
une valeur variable à un paramètre qui, lui, est toujours le même. On est
donc assez loin des cas où on a besoin de construire une expression à la
volée. Et finalement, pourquoi faire compliqué et risqué quand on peut faire
simple et sûr?
Quoi qu'il en soit, la commandlet Invoke-Expression est à manipuler avec
précaution, tout comme Execute et ExecuteGlobal en VBScript d'ailleur
;-)
"Jacques Barathon [MS]" a écrit dans le message de news: <...>
En effet, je vous l'accorde, il peut y avoir un risque d'injection de code malveillant. Cependant, le risque est présent uniquement si le script s'exécute sous une autorité différente de celle de l'utilisateur, ce qui, je pense, est rarement le cas d'un script Powershell d'administration. Ci-dessous un lien vers un article fort intéressant : http://blogs.msdn.com/powershell/archive/2006/11/23/protecting-against-malicious-code-injection.aspx
"Code injection attacks become attacks once they cross a trust boundary. If they don't cross a trust boundary, they are just a complicated and buggy way of doing what a user could already do." - Lee Holmes - PowerShell Team
L'avis de Lee est tout à fait juste, mais il parle "d'attaque". Je n'allais pas jusque là. Evidemment, dans mon exemple j'ai un peu trop forcé le trait pour représenter une faute de frappe ou une simple confusion dans ce qui est demandé, mais je voulais attirer votre attention sur une source importante de comportements imprévisibles voire destructeurs en cas d'erreur.
Surtout que dans ce cas précis, l'utilisation d'invoke-expression est totalement inutile, l'objectif initial de Bruno étant simplement de passer une valeur variable à un paramètre qui, lui, est toujours le même. On est donc assez loin des cas où on a besoin de construire une expression à la volée. Et finalement, pourquoi faire compliqué et risqué quand on peut faire simple et sûr?
Quoi qu'il en soit, la commandlet Invoke-Expression est à manipuler avec précaution, tout comme Execute et ExecuteGlobal en VBScript d'ailleur ;-)
Tout à fait Gilles. :-)
Jacques
Jacques Barathon [MS]
"Michel Claveau" <Enleverles wrote in message news:
Bonsoir !
la solution de Michel est de TRES LOIN la plus...
Combien te dois-je ? Un panaché, ça ira ?
Ah oui, un panaché je veux bien! Et en terrasse s'il te plaît! :-)
Jacques
"Michel Claveau" <Enleverles XX.mcXX@XmXclaveauXX.XX.com> wrote in message
news:mn.4cdd7d75642812cc.34209@XmXclaveauXX.XX.com...
Bonsoir !
la solution de Michel est de TRES LOIN la plus...
Combien te dois-je ? Un panaché, ça ira ?
Ah oui, un panaché je veux bien! Et en terrasse s'il te plaît! :-)