¿Qué significa: "Un proceso hijo puede heredar el identificador"?

Question

Hay algunos objetos de Win32 que según el SDK pueden "heredarse" a los procesos secundarios creados por el proceso dado. (Eventos, mutexes, pipes, ...)

¿Qué significa eso en realidad?

Digamos que tengo un objeto de evento con nombre, creado con CreateEvent, una vez con bInheritHandle == true, y otra vez == false.

Ahora comienzo un proceso secundario. ¿Cómo afectan esos dos controles de eventos al proceso hijo? ¿En qué escenarios difieren?

Answer 1

Si crea/abre un objeto y permite que ese identificador se herede, los procesos secundarios que pueden heredar identificadores (por ejemplo, puede especificar bInheritHandles = TRUE para CreateProcess) tendrán copias de esos identificadores. Esos identificadores heredados tendrán los mismos valores de identificador que los identificadores principales. Así, por ejemplo:

• CreateEvent devuelve un identificador para un objeto de evento, mango es 0x1234.
• Permite heredar ese identificador.
• Crea un proceso secundario que hereda sus identificadores.
• Ese proceso secundario ahora puede usar el controlador 0x1234 sin tener que llamar al CreateEvent o OpenEvent. Por ejemplo, podría pasar el valor del controlador en la línea de comando del proceso hijo.

Esto es útil para objetos sin nombre: dado que no tienen nombre, otros procesos no pueden abrirlos. Usando handle inheritance, los procesos hijos pueden obtener identificadores para objetos sin nombre si así lo desean.

Answer 2

Si crea un evento y permite que los procesos hijo hereden el identificador, el proceso secundario puede usar el identificador para el mismo objeto creado por el padre. Esto se puede utilizar de forma tal que un niño use un identificador de evento para enviar una señal al padre cuando se haya completado una tarea (hay muchos otros usos para los identificadores de objetos de eventos heredables).

EDITAR: Se eliminó la desinformación.

Answer 3

Un punto que no se ha hecho en las respuestas existentes es que permitir que un proceso secundario herede identificadores no solo afecta el proceso secundario; también puede afectar la vida útil del objeto al que se refieren las asas. Si el proceso principal finaliza, los identificadores en el proceso hijo mantendrán vivo el objeto.

Al permitir que un proceso hijo herede identificadores, debe considerar si dará como resultado un objeto que dure más de lo que debería; por ejemplo, algunas aplicaciones solo quieren permitir que una instancia se ejecute a la vez, y pueden hacer eso al crear un objeto de evento con un nombre de pila y ver si ya existe. Si crean un proceso hijo que hereda ese objeto de evento y sobrevive al padre, podría dar lugar a un falso positivo.

Más comúnmente, un identificador heredado de un archivo puede hacer que el archivo permanezca en uso (y, por lo tanto, inaccesible) más de lo que debería.

Por esta razón, la mejor práctica es:

• Hacer todos los mangos como no se puede heredar a menos que necesiten específicamente para ser heredada.

• Si un subproceso no necesita heredar identificadores, pase FALSE para bInheritHandles.

• Si un subproceso necesita heredar identificadores, only allow it to inherit those specific handles that are needed.

Por otro lado, esto a veces puede ser útil; por ejemplo, si quiere el proceso hijo para que cuente como una instancia del proceso principal, o para que un archivo permanezca inaccesible hasta que el hijo haya salido. Otro truco es hacer que un niño herede un identificador de un objeto nombrado y luego usar la existencia o inexistencia del objeto para determinar si el hijo aún está vivo, sin tener que pasar por un identificador de proceso o proceso.