Discussion :

[bstevy]

Bonjour à tous,

J'ai un petit problème lors de l'execution d'un script.
Voici le contexte.

J'ai un script call_ftp.bat que j'execute avec comme parameter "set1".
A partir de la, je vais chercher dans un fichier param.txt la ligne qui commence par "set1" et qui contient une liste de parametre de connexion qui me permette d'executer mon batch suivant batch_ftp.bat

ca va donner un truc comme ca :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
for /f "tokens=1* delims=/ " %%A in ('findstr /b /c:"%1 "param.txt"') do (
	SET PARM_LIST=%%B
)
CMD /C "Batch_ftp.bat %PARM_LIST%"

Juste que la, je pense que c'est pas trop compliqué.

Sauf qu'après ca se complique...


Pour des raisons de sécurité, le mot de passe est stocké dans une variable d'environnement.
Donc, dans mon fichier de parametre, il est stocké de la facon suivante : %USER1_PWD% ; et cette variable est valorisée (vérifié en faisant un set)

Ensuite, j'execute mon script via un scheduleur nommé TNG. Et là, c'est le drame. La variable d'environnement ne récupère pas du tout sa valeur.
Si je lance ma commande via CMD, j'ai aucun soucis... mais via TNG, ca ne valorise pas. Pourtant, ca valorise %TMP%, donc ce n'est pas un problème de valorisation direct, je pense plutot que TNG doit executer le scirpt avec un autre utilisateur. Un peu comme s'il faisait un "su" en shell... sauf que je sais pas si c'est faisable en windows.

Je vais voir à executer un script via TNG :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

set > %TMP%\set.txt

pour voir ce qu'il me sort.

Est ce que qlq un aurait une experience similaire avec un scheduleur, ou le meme ? une idée d'ou pourrait venir le probleme et comment le palier ?

Merci d'avance.


Steven




EDIT : J'ai obtenu le retour du set executé avec TNG. Je n'ai pas mes variables d'environnement dedans.
Alors que je les ai quand j'affiche sur un cmd.
De plus, la variable %USERNAME% est bien celle de mon utilisateur.
Donc là, je suis un peu coincé.
Qu'est ce qui pourrait faire qu'un programme n'ai plus acces à la liste des variables utilisateurs créées manuellement ?

[InitSreen]

Bonjour,

tu ne devrais pas mettre un mot de passe dans une variable d'environnement car si un espace mémoire n'est accessible qu'au programme qui la créé, se n'est pas le cas des variables d'environnement qui elle sont accessible à tout le monde. Ensuite ton mdp doit contenir un ou plusieurs espaces, c'est la seule raison qui provoque se genre d'erreur, si tu veux quand même utiliser une variable place le mdp entre guillemets.

Sinon, créer un utilisateur spécifique pour cette opération du genre "Opérateur FTP", puis dans le registre créer une clé qui contient le mdp. Une fois créé, les ACLs de la clé qui contient le mdp doivent êtres modifier avec la commande "regini" afin de n'être accessible que pour l'utilisateur (pas l'admin et pas le système en cas d'exploit à ce niveau). Le contenu de la clé peut être récupère via la commande "reg query" mais ne place pas le mdp dans une variable, utilise à la place une boucle for. Les ACLs de ton script doivent aussi être modifier afin d'empêcher toutes écritures inappropriés. Ton script ainsi créé/modifié pourra être lancé via "runas" qui est équivalant à sudo du monde Unix/Linux (%UserName%="Opérateur FTP").

[bstevy]

Merci pour ce petit cours de sécutité, mais ce n'est vraiment pas l'objet ici ^^

J'en parlerai à l'occasion à mes chefs, mais la politique de sécurité est telle qu'ils preferent avoir le mdp dans une variable d'environnement plutôt que dans un script (ce que j'avais fait au début).

Indépendament du mot de passe - j'ai pris cet exemple car c'est mon cas, mais je pourrais avoir une toute autre information dans ma variable d'environnement - le point ici, c'est bien le fait que ma variable d'environnement n'apparait pas quand j'execute mon script via mon scheduler.

Nous pensons que la solution serait peut etre de redémarrer le scheduler, mais vu que c'est de la prod, c'est pas tellement faisable.

[InitSreen]

ça peut être dû à l'utilisateur qui lance la tache, vérifie qu'il a bien la variable d'environnement défini dans la clé "HKU\<SID_de_l'utilisateur>\Environnement". Si c'est le cas peut-être qu'il faudrait utilisé "reg load" dans ton script pour chargé les modifs qui ne devait pas être présente lors du lancement (et donc inexistante dans le processus de le scheduler) mais tu en reviens à ton pb de mot de passe dans un fichier. Après prod ou pas, tu dois bien avoir un créneau pour la maintenance (vers 4h du matin par exemple) sinon change de taf: un chef de projet qu'a pas prévu ça vas t'en faire voir des vertes et des pas mûre.