Subject: Re: job-control shell trouble
To: None <tech-userlevel@NetBSD.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Date: 12/26/2004 15:11:12
>> 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
> 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
> 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 firstname.lastname@example.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B