Job handle in target app

[vefatica]

When I add an already-running app to a job at job-creation time, that already-running app gets a handle to the job object.

v:\> echo Host PID is %_PID
Host PID is 4248

v:\> jobs /n=job1 /k 2296

v:\> handle -a | egrep "tcc.*pid|job"
tcc.exe pid: 4248 zz\vefatica
  2B4: Job           \Sessions\2\BaseNamedObjects\job1
tcc.exe pid: 2296 zz\vefatica
  1FC: Job           \Sessions\2\BaseNamedObjects\job1

v:\>

I fooled with AssignProcessToJobObject() a bit and I could not make that happen! How does it happen? Can you stop it from happening? It messes up using /K to make processes in job objects terminate along with the process that created the job.

 

[felixkasza]

It's fairly easy, from a programmer's point of view: Create the job object, passing in a SECURITY_ATTRIBUTES structure with sa.bInheritHandle = TRUE. Any child process created henceforth will inherit this handle, if it is created with the bInheritHandles argument set to TRUE. Such a child process will receive copies of all inheritable handles, making it easy to pass the standard in/out/error handles.

A (to me) preferrable way is to do the handle inheritance as above, but to call CreateProcess…() with a STARTUPINFOEX structure. Before the call, when prepping the STARTUPINFOEX, one hangs an attribute list off of it, adding the PROC_THREAD_ATTRIBUTE_HANDLE_LIST. This restricts the handles inherited by the child to the ones specified in this attribute. Finally, call CreateProcess…() with EXTENDED_STARTUPINFO_PRESENT in dwCreationFlags.

 

[vefatica]

Child processes (created with START /JOB) are OK; they don't get a handle to the job object and so will terminate along with their parent if /K is used in creating the job object.

I'm complaining about an already-running process, added to a job object at creation time with "JOBS /N=name ... PID". TCC seems to be going out of its way, with DuplicateHandle() to inject a job object handle into the process. That thwarts the strategy of using /K to make processes in job objects terminate when the process creating the job object terminates. And while there may be some reason for it, it's not necessary. A simple OpenProcess() ... AssignProcessToJobObject() will put the already-running process into the job object without giving that process a handle to the job object.

 

[felixkasza]

I owe you an apology for not even having noticed that when I read your original posting. That a running process might be force-fed a handle to the very job object that is supposed to keep it under control is, uh, rather surprising, and I didn't consider that possibility … anyway, sorry!

 

[rconn]

When I add an already-running app to a job at job-creation time, that already-running app gets a handle to the job object.

WAD. JOBS duplicates the job handle into the already-running app, because that's necessary if the app has any security limitations.

A /K will close the job when all apps attached to the job exit, not when the process creating the job object terminates.