Very Computer

In reading about vfork, it is suggested that a vfork be followed
immediately with an exec. I'm trying to understand the possible
implications of a program that does a bunch of I/O redirection
in the child before the exec.

Here's a code fragment I wonder about:
= =

    iop = NULL;
    switch (pid = vfork()) {
    case -1:                    /* error */
        (void) close(pdes[0]);
        (void) close(pdes[1]);
        goto pfree;
        /* NOTREACHED */
    case 0:                 /* child */
        if (*type == 'r') {
            if (pdes[1] != 1) {
                dup2(pdes[1], 1);
                if (closestderr)
                    (void) close(2);
                else
                    dup2(pdes[1], 2);  /* stderr, too! */
                (void) close(pdes[1]);
            }
            (void) close(pdes[0]);
        } else {
            if (pdes[0] != 0) {
                dup2(pdes[0], 0);
                (void) close(pdes[0]);
            }
            (void) close(pdes[1]);
        }
        for (i = 3; i < fds; i++)
                close(i);
        /* begin CERT suggested fixes */
        close(0);
        i = geteuid();
        delay_signaling(); /* we can't allow any signals while euid==0: kinch */
        seteuid(0);
        setgid(getegid());
        setuid(i);
        enable_signaling(); /* we can allow signals once again: kinch */
        /* end CERT suggested fixes */
        execv(gargv[0], gargv);
        _exit(1);
    }
    /* parent; assume fdopen can't fail...  */
    if (*type == 'r') {
        iop = fdopen(pdes[0], type);
        (void) close(pdes[1]);
    } else {
        iop = fdopen(pdes[1], type);
        (void) close(pdes[0]);
    }
    pids[fileno(iop)] = pid;

= =

(This is from the wuftpd version wu-2.4.2-academ[BETA-12] in the ftpd_popen
 routine in popen.c, for those who care about context.)

I'm concerned that all that messing about in the child will affect
the memory space of the parent too, since this is a vfork, but
I'm not sure exactly  what is shared across a vfork.

Stuff using this code has bus errors and segmentation faults more
that I'd like so I'm looking for potentital memory clobbers.

--

| In reading about vfork, it is suggested that a vfork be followed
| immediately with an exec. I'm trying to understand the possible
| implications of a program that does a bunch of I/O redirection
| in the child before the exec.
|
| Here's a code fragment I wonder about:

 [ ... ]
|
| (This is from the wuftpd version wu-2.4.2-academ[BETA-12] in the ftpd_popen
|  routine in popen.c, for those who care about context.)
|
| I'm concerned that all that messing about in the child will affect
| the memory space of the parent too, since this is a vfork, but
| I'm not sure exactly  what is shared across a vfork.
|
| Stuff using this code has bus errors and segmentation faults more
| that I'd like so I'm looking for potentital memory clobbers.

Pretty much any libc call might be implemented in a way that changes the
state of the library, making it unsuitable between a vfork() and an
exec().  Under Solaris this is the case with signal(), which is one
thing you'd commonly want to call between [v]fork() and exec().  In
doubt, use fork().

        Roger

Quote:>In reading about vfork, it is suggested that a vfork be followed
>immediately with an exec. I'm trying to understand the possible
>implications of a program that does a bunch of I/O redirection
>in the child before the exec.

I can't think of using vfork unless I wanted to execute lots of other
proccesses, if it came to that, I'd fork, then change I/O and vfork the X
many proccesses this would be more effecient.....

------------------------------------------------------------------------------
Thamer Al-Herbish (ShadowS)     The views expressed here, have no relevance


                -=whitefang dawt kawm=-
-------------------------------------------------------------------------------

Quote:

>In reading about vfork, it is suggested that a vfork be followed
>immediately with an exec. I'm trying to understand the possible
>implications of a program that does a bunch of I/O redirection
>in the child before the exec.

--
James Youngman       VG Gas Analysis Systems |The trouble with the rat-race
 Before sending advertising material, read   |is, even if you win, you're
http://www.law.cornell.edu/uscode/47/227.html|still a rat.

Quote:

>IMHO it's not worth the worry since most UNIX implementations implement vfork()
>with fork() since they have COW pages -- fork() just doesn't have the overhead
>it used to.

--

``Not only is UNIX dead, but it's starting to smell really bad.''  -- rob

Quote:>vfork() always was, and always will be, a crock.  stick to fork().

Michael Gordon
--
Quidquid latine dictum sit, altum viditur.

: >vfork() always was, and always will be, a crock.  stick to fork().
:
: Agreed, the semantics of vfork() are a little weird, but it does have
: some uses.

Last time I checked, in Linux vfork() is implemented as fork().

--

Linux Plug-and-Play Kernel Project http://www.redhat.com/linux-info/pnp/
XFree86 Matrox Team http://www.bf.rmit.edu.au/~ajv/xf86-matrox.html