none
Process.Start provoque une exception accés refusé RRS feed

  • Question

  • Bonjour,

     

    Je suis sous windows XP SP3.

    Je suis dans un programme d'installation créé avec visual studio 2008

    Ce programme d'installation lance un programme VB qui lui-même essaye de lancer une application VB aussi dans la session de l'utilisateur. Voici le code :

     

     

     

    Code Snippet

    Dim pi As New Process  

    pi.StartInfo.Arguments = "" 

    pi.StartInfo.FileName = String.Concat(pathW, "CAWebService2005MyPC.exe")  

    pi.StartInfo.UserName = cmdArgs(1)  

    pi.StartInfo.LoadUserProfile = True 

    pi.StartInfo.Password = New System.Security.SecureString()  

    For ind = 0 To cmdArgs(2).Length - 1  

        pi.StartInfo.Password.AppendChar(cmdArgs(2).Chars(ind))  

    Next 

    pi.StartInfo.Domain = cmdArgs(3)  

    pi.StartInfo.UseShellExecute = False 

    pi.StartInfo.WorkingDirectory = pathW  

    pi.Start()

     

    Ceci provoque une exception accès refusé sur la ligne pi.Start.

     

    J'ai aussi essayé en faisant une impersonnalisation comme ceci :

     

    Code Snippet

    Using person As NetFw.Impersonator = New NetFw.Impersonator(pi.StartInfo.Domain, pi.StartInfo.UserName, cmdArgs(2))
        pi.Start()
    End Using

     

     

    Mais cela donne le même résultat.

    Mon problème est comment lancer une application dans la session de l'utilisateur avec son accord eventuel à partir d'un setup visual studio 2008.

    Le plus étonnant est qu'il n'y a pas de problème pour lancer cette application dans le menu demarrage de l'utilisateur, alors évidement, je peux toujours provoquer un reboot (chose que je ne sait pas faire non plus dans un setup), mais c'est un peut le marteau pilon pour écraser la mouche.

    Merci d'avance à tous ceux qui prendront le temps de me répondre ces problèmes de sécurité étant toujours une galère pas possible.

    Cordialement,

    vendredi 4 juillet 2008 08:03

Réponses

  • Bonjour,
    Le problème provient du droit exécution, il faut autoriser l'utilisateur ou le service qui lance l'application à exécuter le programme.
    le plus simple est de donner tout les droits sur le répertoire de l'application à exécuter au service ou à l'utilisateur du domaine sur la machine local.
    Sous Vista il en est de même, problème d'autorisation dû à la sécurité "Contrôle des comptes Utilisateurs...." dans les utilisateurs.
    Décochez cette sécurité (qui à mon goût ne sert à rien), et si le problème persiste ajouter les droits à l'utilisateur ou service.
    lundi 11 mai 2009 10:35

Toutes les réponses

  • Es-ce que tu as vérifier la valeur de FileName? il pourrait te manquer le dernier "\".
    vendredi 4 juillet 2008 12:04
    Modérateur
  • Oui bien sûr car voilà le code :

     

    Code Snippet

        Dim path As String = pathAppli

        If pathW.Chars(pathW.Length - 1) <> "\"c Then
          pathW += "\"
        End If

     

     

     

    vendredi 4 juillet 2008 13:56
  • Bonjour

    Avec l'arrivée de Vista, j'ai exactement le même problème.
    Un service lançant un exe ... mais pas sous la bonne session.

    Je cherche toujours.

    As-tu fini par résoudre ton problème ?
    mardi 4 novembre 2008 14:28
  • Et non malheureusement! Si vous êtes plus chanceux que moi, faites en moi profiter, s'il vous plait, merci d'avance

     

    jeudi 6 novembre 2008 10:45
  • J'ai maintenant un service qui lance un exe sur le bureau de la session actuellement affichée et qui en plus se lance en utilisant les droits de cette session, tout cela depuis le service qui lui est en session 0 avec l'utilisateur SYSTEM.

    Le seul hic c'est que j'ai fait ça en trafiquant un projet C++ récupéré sur le net.

    Ça marche bien mais je voudrais le convertir en vb.net pour m'en resservir (ou au pire en faire une DLL).

    Et là j'ai du mal avec la configuration du projet C++ ...

    Si ça t'intéresse dis le moi je pourrais t'envoyer ce projet par mail.

    Et si tu parviens à en faire soit une traduction VB.Net soit un projet générant une DLL là c'est moi qui serait intéressé !!
    jeudi 6 novembre 2008 12:01
  • Bonjour,

    Oui biensûr, mais je ne peux garantir le résultat, mais je peux essayer. J'ai une bonne connaisance du C++.

    Tu peux m'envoyer le code à cette adresse behemothe@msn.com

    Cordialement;

    mercredi 12 novembre 2008 09:57
  • Bonjour

    En fait c'est bon j'ai fait une DLL avec juste une fonction qui attend le nom du prog à lancer et les paramètres de démarrage.
    Cette fonction étant dans un DLL, on peut s'en servir n'importe où : avec du C++ ou du VB.NET sans probleme.

    Si tu en veux le projet (et la DLL compilée) pas de souci.

    En tout cas de mon coté, ça fait pile ce que je voulais à savoir : depuis mon service (appartenant à la session 0 car utilisateur SYSTEM) j'arrive à lancer un exe avec ses paramètres et cela sur la console c'est à dire sur la session actuellement affichée et cela sans avoir aucune idée de qui est loggé sur la machine en ce moment. Et l'exe se lance avec les droits de l'utilisateur loggé et non ceux de SYSTEM (du coup la clé HK_CURRENT_USER est utilisable).

    Merci quand même pour ton aide

    mercredi 12 novembre 2008 12:41
  • Merci de quoi, je n'ai pas fait grand chose! En fait je suis interressé par ta DLL si tu es d'accord, car j'ai ce problème lors de l'installation de mon application, lorsque je veux lancer l'application dans le compte de l'utilisateur logger.

    Cette application ensuite discute avec mon service via TCP/IP, pour executer les commandes du service dans l'espace utilisateur.  En fait mon service est un ensemble de WebService en .NET

    C'est la méthode préconisée par MS.

    En tout les merci pour l'info et bravo.

     

    mercredi 12 novembre 2008 14:52
  • Bonjour,

    Je rencontre les problématiques que celle que vous décrivez.
    Je suis donc intéressé par votre DLL et/ou projet.

    Merci,

    JM
    lundi 27 avril 2009 14:59

  • Bonjour,

    Il me semble qu'il y a plusieurs incompréhensions dans le code (sauf si je me trompe, et oui l'erreur est encore humaine), je m'explique :
    - Pourquoi mettre un Arguments a "rien" mieux ne pas le mettre ? (pi.StartInfo.Arguments = ""  )
    - Dans "pi.StartInfo.FileName = String .Concat(pathW, "CAWebService2005MyPC.exe" ) " il faut mieux utiliser l'option combine path comme ça cela évite certaine vérification, cela doit ressembler a pi.StartInfo.FileName = System.IO.Path.Combine( pathW, "CAWebService2005MyPC.exe")

    il y a aussi " pi.StartInfo.Password = New System.Security.SecureString()" là il demande une chaine SecureString pourquoi lui mettre une nouvelle instance (New) sans lui donner la chaine SecureString ? je pense qu'il faut mieux lui donner directement non ?

    Dans ce que je viens de dire il n'y a aucune attaque personnel et aucune critique, ce n'est que certaines interrogations en vers mon égard et je me permet de pauser les questions ...

    Voila comment je vois le code au final, il sera peut etre necessaire de faire quelle que modification pour qu'il puisse fonctionne comme on veux

           

            Dim pi As New Process
            Dim MonPassword As New Security.SecureString
    
            With pi.StartInfo
                .FileName = Path.Combine(pathW, "CAWebService2005MyPC.exe")
                .Domain = cmdArgs(3)
                .UserName = cmdArgs(1)
                .LoadUserProfile = True
                .UseShellExecute = False
                .WorkingDirectory = pathW
    
                For Each c As Char In cmdArgs(2).ToCharArray
                    MonPassword.AppendChar(c)
                Next
    
                .Password = MonPassword
    
            End With
            Try
                pi.Start()
            Catch ex As Exception
                MsgBox(ex.Message)
            End Try

     

    Sinon il y a un programme qui existe qui est PSEXEC qui ce trouve dans le pack PSTOOLS il est tres puissant, ce programme sers a executer des programmes a distance (sur une autre machine) d'un réseau local

     

     


    Cordialement,
    lundi 27 avril 2009 17:52
    Auteur de réponse
  • Bonjour,
    Le problème provient du droit exécution, il faut autoriser l'utilisateur ou le service qui lance l'application à exécuter le programme.
    le plus simple est de donner tout les droits sur le répertoire de l'application à exécuter au service ou à l'utilisateur du domaine sur la machine local.
    Sous Vista il en est de même, problème d'autorisation dû à la sécurité "Contrôle des comptes Utilisateurs...." dans les utilisateurs.
    Décochez cette sécurité (qui à mon goût ne sert à rien), et si le problème persiste ajouter les droits à l'utilisateur ou service.
    lundi 11 mai 2009 10:35