rfork problem

John Baldwin jhb at FreeBSD.org
Tue Nov 4 11:35:07 PST 2003


On 04-Nov-2003 David Schultz wrote:
> On Tue, Nov 04, 2003, Igor Serikov wrote:
>> 
>>   David,
>> 
>> Is it okay to have a condition that can be created by a mortal user and 
>> then cannot be changed by the root? The waiting process cannot be killed 
>> and would keep "waiting" till system reboot.
> 
> Aah, I see.  No, it's not okay that a non-root user can create an
> unkillable process.  -CURRENT doesn't have this problem because it
> rightly fails when a userland program tries to use RFPPWAIT.  (It
> isn't supposed to be available to userland, which is why it isn't
> documented.)  The problem could be fixed by backporting the
> relevant bits from -CURRENT.  
> 
>> I do not think it is a good idea to make ppwait state uninterruptible in 
>> any case.
> 
> I do not think it would be safe to deliver a signal to a parent
> process while a vforked child is borrowing its address space.
> 
> Here's a patch against -STABLE:
> 
> Index: kern_fork.c
> ===================================================================
> RCS file: /cvs/src/sys/kern/kern_fork.c,v
> retrieving revision 1.72.2.15
> diff -u -r1.72.2.15 kern_fork.c
> --- kern_fork.c       28 Sep 2003 11:08:31 -0000      1.72.2.15
> +++ kern_fork.c       4 Nov 2003 19:13:33 -0000
> @@ -130,6 +130,9 @@
>       int error;
>       struct proc *p2;
>  
> +     /* Don't allow kernel only flags. */
> +     if ((uap->flags & RFKERNELONLY) != 0)
> +             return (EINVAL);
>       error = fork1(p, uap->flags, &p2);
>       if (error == 0) {
>               p->p_retval[0] = p2 ? p2->p_pid : 0;

You'll need to backport RFKERNELONLY as well in sys/unistd.h as that
isn't in 4.x AFAIK.

-- 

John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/


More information about the freebsd-hackers mailing list