>> It is admittedly _unlikely_ that all the old processes will die and
>> some other process in the same session will recreate the process
>> group, without my having noticed that all the old processes have
>> died and thus realizing that the process group is gone.  But
>> "unlikely" really isn't good enough.
> In this particular case, it is good enough.  From the manual page for
> setpgid:

>      If the invoker is not the super-user, then the affected process
>      must have the same effective user-id as the invoker or be a
>      descendant of the invoking process.

Yes, the *affected* process.  But the affected process is always an
inferior of my shell.

My example looks like this:

 - session leader
    - some other process, pid A, pgrp A
    - my new shell, pid B, pgrp B

Now, my shell, B, forks process C.  As the first process of a new job,
its PID gets used for the pgrp for the job, so it gets pgrp C.

This process runs for a while, then dies.  My shell reaps the zombie,
forks again, and gets PID D.  Now, I have a problem.

If process C forked a child which is still around, pgrp C is still
around, and C is the right pgrp to put D into.  But if C's pgrp died
with it, then it's possible that, after I reaped C's zombie, A forked,
got PID C, and has recreated pgrp C - and C is then the wrong pgrp for
me to use for D.  But in either case, an attempt to put D into pgrp C
will succeed.  I can't see any way for B to tell which case obtains.

> If you are root, then you can do it anyway; there is no security
> issue.
> If you are not root, then you must be doing it to yourself.

Not a security issue, but a correctness issue.  Root or not, I don't
want to put processes into process groups that they really don't belong
in - perhaps *especially* if I'm running as root.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B