Qu'est-ce que cela signifie: "Un processus fils peut hériter de la poignée"?

Question

Il existe certains objets Win32 qui, selon le SDK, peuvent être "hérités" par les processus enfants créés par le processus donné. (Événements, mutex, pipes, ...)

Qu'est-ce que cela signifie réellement? Disons que j'ai un objet événement nommé, créé avec CreateEvent, une fois avec bInheritHandle == true, et un autre fois == false.

Maintenant, je commence un processus enfant. Comment ces deux handles d'événements affectent-ils le processus enfant? Dans quels scénarios sont-ils différents?

Answer 1

Si vous créez/ouvrez un objet et autorisez l'héritage de ce handle, les processus enfants autorisés à hériter des handles (par exemple, vous pouvez spécifier bInheritHandles = TRUE pour CreateProcess) auront des copies de ces descripteurs. Ces handles hérités auront les mêmes valeurs de handles que les handles parents. Ainsi, par exemple:

• CreateEvent retourne une poignée pour un objet événement, la poignée est 0x1234.
• Vous autorisez l'héritage de ce handle.
• Vous créez un processus enfant qui hérite de vos handles.
• Ce processus enfant peut maintenant utiliser gérer 0x1234 sans avoir à appeler CreateEvent ou OpenEvent. Vous pouvez par exemple passer la valeur du handle dans la ligne de commande du processus enfant.

Ceci est utile pour les objets sans nom - puisqu'ils ne sont pas nommés, les autres processus ne peuvent pas les ouvrir. À l'aide de l'héritage des handles, les processus enfants peuvent obtenir des handles vers des objets sans nom si vous le souhaitez.

Answer 2

Si vous créez un événement et autorisez l'héritage du handle par des processus enfants, le processus enfant peut utiliser le handle vers le même objet que celui créé par le parent. Cela peut être utilisé d'une manière où un enfant utilise un handle d'événement pour signaler au parent quand une tâche a été accomplie (il y a beaucoup d'autres utilisations pour les handles d'objet d'événement héritables).

EDIT: Suppression de la désinformation.

Answer 3

Un point qui n'a pas été fait dans les réponses existantes est qu'autoriser un processus fils à hériter des poignées n'affecte pas seulement le processus fils; cela peut également affecter la durée de vie de l'objet auquel se réfèrent les poignées. Si le processus parent se termine, les poignées du processus enfant maintiendront l'objet en vie. Lorsque vous permettez à un processus fils d'hériter de descripteurs, vous devez déterminer si un objet va vivre plus longtemps qu'il ne le devrait; Par exemple, certaines applications ne souhaitent autoriser qu'une instance à s'exécuter à la fois, et peuvent le faire en créant un objet événement avec un nom donné et en vérifiant s'il existe déjà. Si elles créent un processus enfant qui hérite de cet objet événement et survivent au parent, cela peut entraîner un faux positif. Plus généralement, un descripteur hérité d'un fichier peut entraîner l'utilisation du fichier (et par conséquent inaccessible) plus longtemps qu'il ne devrait l'être.

Pour cette raison, la meilleure pratique consiste à:

• Faire toutes les poignées comme non héritable à moins qu'ils ne doivent spécifiquement être héritées.

• Si un sous-processus n'a pas besoin d'hériter de descripteurs, transmettez FALSE pour bInheritHandles.

• Si un sous-processus doit hériter des handles, only allow it to inherit those specific handles that are needed.

D'autre part, cela peut parfois être utile; Par exemple, si vous souhaitez le processus enfant à compter en tant qu'instance du processus parent ou pour qu'un fichier reste inaccessible jusqu'à ce que l'enfant a quitté. Une autre astuce consiste à demander à un enfant d'hériter d'un descripteur d'un objet nommé, puis d'utiliser l'existence ou l'inexistence de l'objet pour déterminer si l'enfant est toujours vivant, sans passer par un identificateur de processus ou de processus.