rfork problem

[David Schultz]

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;