Discussion :

[homeostasie]

Bonjour,

Pour résumer le contexte, je suis entrain de programmer un service qui une fois lançé, charge une DLL.

Lors du chargement de la DLL, un thread est créé à partir de "DLL_PROCESS_ATTACH", celui-ci s'exécute normalement. Dans ce thread, je désire créer un nouveau thread et là, badaboum, celui-ci ne s'exécute jamais...

Pourtant, à l'aide de trace, je constate que je passe bien dans "DLL_THREAD_ATTACH".

Maintenant, pour vérifier si cela venait du contexte d'éxécution (dans un service SYSTEM), je fais en sorte d'exécuter mon programme en mode utilisateur. Et là, aucun soucis, tout fonctionne.

Auriez vous une idée/solution d'un tel comportement?

Merci

Nicolas

[ram-0000]

Par hasard, dans cette DLL, tu n'utiliserai pas quelque chose qui n'existe pas pour SYSTEM mais qui fonctionne pour un utilisateur normal.

Un exemple, il ne faut pas utiliser wininet dans un service car wininet utilise HKCU et HKCU n'a pas de sens pour SYSTEM

Mon idée à 2 balles

[homeostasie]

Par hasard, dans cette DLL, tu n'utiliserai pas quelque chose qui n'existe pas pour SYSTEM mais qui fonctionne pour un utilisateur normal.

C'était une idée à prendre en compte en effet!

Mais mon problème venait d'une grossière erreur de ma part.

En fait pour debugger ma DLL en release, j'utilse des traces via:

Code :

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

1
2
MessageBox(NULL, "Thread: Debut", "Debug DLL en release", MB_SERVICE_NOTIFICATION);

Et lorsque j'ai fait un copié collé d'une partie de mon programme utilisateur, j'ai omis de modifier le type de flag et je l'ai laissé à MB_OK. Donc je ne voyais pas ma message box... Complètement zappé le truc et je cherchais ailleurs le problème.


Tant que j'y suis, je vais traité d'un autre aspect. Je désire rendre mon service d'une "certaine manière" interactif.
Pour cela, j'ai créé une fenêtre avec une structure WNDCLASSEX et l'appel de la fonction CreateWindowEx() à partir d'un thread. J'obiens bien un handle sur la fenêtre. Dans le thread en question, je mets ma boucle de message.

Le but de cela est de pouvoir entre autre controler mon service à partir d'une application utilisateur au travers l'envoie de message WM_APP+x. Mais apparemment mes messages ne sont pas récupérés donc pas de traitement.

Il y a t'il un moyen de parvenir à cela? Peut être ais je passer de mauvaises options lors de la création de mon service ou de ma fenêtre?

Sinon, je peux utiliserautre technique de communication inter-processus tel que le pipe ou l'ouverture d'une socket en locale mais vu que j'ai commencé par l'envoie de message applicatif, je voudrais aller jusqu'au bout.

Nicolas

[ram-0000]

Le but de cela est de pouvoir entre autre controler mon service à partir d'une application utilisateur au travers l'envoie de message WM_APP+x. Mais apparemment mes messages ne sont pas récupérés donc pas de traitement.

Si j'ai bien compris, une application utilisateur fait un SendMessage (ou PostMessage) sur le handle de la fenêtre du service.

Est ce que le SendMessage (ou PostMessage) se passe bien (code de retour ?).

Est ce que tu as le droit en tant qu'utilisatuer d'interagir avec un handle qui appartient à SYSTEM (problème de sécurité et de privilèges) ?

[homeostasie]

Si j'ai bien compris, une application utilisateur fait un SendMessage (ou PostMessage) sur le handle de la fenêtre du service.

Oui, c'est bien cela.

Est ce que le SendMessage (ou PostMessage) se passe bien (code de retour ?).

J'utilise SendMessage. Le message est apparemment envoyé puisque c'est une fonction bloquante et je peux poursuivre mon code. Par contre, le résultat renvoyé est toujours 0. La fonction de traitement du message devrait afficher une messagebox() et retourner 1.
Donc le message serait il traité par une autre boucle à messages?

Est ce que tu as le droit en tant qu'utilisatuer d'interagir avec un handle qui appartient à SYSTEM (problème de sécurité et de privilèges) ?

En effet pour surement des problèmes de sécurité, cela n'est pas recommandé (du fait qu'une application utilsateur puisse intérargir avec un service SYSTEM).
D'ailleurs msdn dit:

Using an Interactive Service
By default, services use a noninteractive window station and cannot interact with the user. However, an interactive service can display a user interface and receive user input.

Caution Services running in an elevated security context, such as the LocalSystem account, should not create a window on the interactive desktop because any other application that is running on the interactive desktop can interact with this window. This exposes the service to any application that a logged-on user executes. Also, services that are running as LocalSystem should not access the interactive desktop by calling the OpenWindowStation or GetThreadDesktop function.


To create an interactive service, do the following when calling the CreateService function:

Specify NULL for the lpServiceStartName parameter to run the service in the context of the LocalSystem account.
Specify the SERVICE_INTERACTIVE_PROCESS flag.
To determine whether a service is running as an interactive service, call the GetProcessWindowStation function to retrieve a handle to the window station, and the GetUserObjectInformation function to test whether the window station has the WSF_VISIBLE attribute.

However, note that the following registry key contains a value, NoInteractiveServices, that controls the effect of SERVICE_INTERACTIVE_PROCESS:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Windows

The NoInteractiveServices value defaults to 0, which means that services with SERVICE_INTERACTIVE_PROCESS are allowed to run interactively. When NoInteractiveServices is set to a nonzero value, no service started thereafter is allowed to run interactively, regardless of whether it has SERVICE_INTERACTIVE_PROCESS.

Important All services run in Terminal Services session 0. Therefore, if an interactive service displays a user interface, it is visible only to the user who connected to session 0. Because there is no way to guarantee that the interactive user is connected to session 0, do not configure a service to run as an interactive service under Terminal Services or on a system that supports fast user switching (fast user switching is implemented using Terminal Services).

C'est donc apparamment possible.

Ce que je constate, c'est que lorsque je crée mon service avec le flag SERVICE_INTERACTIVE_PROCESS, CreateService() echoue et me retourne un handle NULL. Ce que je ne comprends pas...

Code :

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

1
2
3
4
5
6
7
8
9
newService= CreateService(scm,
        SERVICE_NAME,
        SERVICE_NAME,
        SERVICE_ALL_ACCESS,
        SERVICE_INTERACTIVE_PROCESS,    //SERVICE_WIN32_OWN_PROCESS, //
        SERVICE_AUTO_START,
        SERVICE_ERROR_NORMAL,
        strPath,
        0,0,0,0,0);

Je dois zapper un truc...

[ram-0000]

et en faisant :

Code :

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

1
2
3
4
5
6
7
8
9
newService= CreateService(scm,
        SERVICE_NAME,
        SERVICE_NAME,
        SERVICE_ALL_ACCESS,
        SERVICE_INTERACTIVE_PROCESS | SERVICE_WIN32_OWN_PROCESS,
        SERVICE_AUTO_START,
        SERVICE_ERROR_NORMAL,
        strPath,
        0,0,0,0,0);

SERVICE_INTERACTIVE_PROCESS est un flag addtionnel à ajouter éventuellement à SERVICE_WIN32_OWN_PROCESS (voir la doc MSDN)

[Médinoc]

As-tu lu ce que MSDN dit sur les threads et DllMain()?

[homeostasie]

SERVICE_INTERACTIVE_PROCESS est un flag addtionnel à ajouter éventuellement à SERVICE_WIN32_OWN_PROCESS

Ok, ca venait de cela, j'ai raté le coup du flag additionnel...
Merci!

As-tu lu ce que MSDN dit sur les threads et DllMain()?

Je viens de faire une recherche et tu dois surement parler de ce lien:
http://msdn.microsoft.com/en-us/library/ms682583.aspx

J'y avais déjà jeté un coup d'oeil il y a un moment de cela et c'est clair qu'il serait bon que je regarde à nouveau.

[Médinoc]

Au passage, je me permets de rappeler que SERVICE_INTERACTIVE_PROCESS a été désactivé sous Vista par mesure de sécurité...

[homeostasie]

Au passage, je me permets de rappeler que SERVICE_INTERACTIVE_PROCESS a été désactivé sous Vista par mesure de sécurité...

Ok, ça peut être bon à savoir si je dois le porter sur une plateforme Vista. Je pense que l'utilisation de tube nommé ou autre moyen de communication IPC doit fonctionner.
D'ailleurs si c'est le cas, je ne vois pas très bien en quoi le fait de désactiver SERVICE_INTERACTIVE_PROCESS fournirait plus de sécurité.

[Médinoc]

Et moi, j'en connais un parfait exemple avec FreeSSHd : Ce service interactif présente une boîte de dialogue de configuration, qui COMPORTE UN BOUTON "PARCOURIR".

Avec la FileDialog qui s'ouvre, n'importe quel utilisateur limité peut ouvrir un explorateur et/ou un invite de commande en tant que NT AUTHORITY/LocalSystem, l'utilisateur qui possède tous les privilèges...

[homeostasie]

Ok, c'est clair que c'est grave!

C'est un problème de conception je trouve. Mais je vois ce que tu veux dire, faire des services interactifs accroient le risque de faille de sécurité.