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