[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sun, 3 Feb 2013 15:47:31 -0500
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: vfork replacement proposal
On Sun, Feb 03, 2013 at 09:36:37PM +0100, Szabolcs Nagy wrote:
> * Rich Felker <dalias@...ifal.cx> [2013-02-03 13:49:23 -0500]:
> > On Mon, Dec 31, 2012 at 03:34:17PM -0500, Rich Felker wrote:
> > > 4. In the child, close the read end of the pipe and then shuffle file
> > > descriptors as needed (for setting up stdin/out for popen, or file
> > > actions for posix_spawn[p]), but with the added stipulations A-C:
> > >
> > > A. Before closing or dup2'ing onto a file descriptor in file actions,
> > > check to see if it's occupied by the pipe fd, and if so, use fcntl
> > > F_DUPFD_CLOEXEC to move it to a new number first.
> > >
> > > B. Before calling open in file actions, always use fcntl with
> > > F_DUPFD_CLOEXEC and close the original pipe fd, to ensure that the
> > > pipe is never occupying the otherwise-lowest-available fd number.
> >
> > I was wrong about (B); the "open" file action does not assign the
> > lowest-available fd, but a caller-chosen fd. Thus, for our purposes,
> > it's just like close or dup2, targetting a known fd number. This means
> > the same logic can be used for all three operations, and it can be
> > based on dup() rather than F_DUPFD_CLOEXEC. Note that F_DUPFD_CLOEXEC
> > is actually not viable because it's missing on slightly-old kernels
> > (up through mid 2.6 series), but we don't need atomicity anyway since
> > this thread/process is fully under posix_spawn's control.
> >
> > Also, I think it would be possible to abandon the "shuffling" logic
> > and compute in advance a safe fd number to put the pipe on.
> >
> > Finally, it seems posix_spawn will be sufficient as a backend for
> > implementing popen, wordexp, and system, so I just put all the logic
> > in posix_spawn itself rather than trying to design a more abstract API
> > with callbacks for the specific caller case.
> >
>
> hm, is it possible to have a non-forking spawn that covers all the
> fork+exec cases? (things one might want to do before exec, eg by
> specifying extra attributes..)
>
> as far as i can see posix_spawn handles these:
>
> setenv
> fds (file_actions, O_CLOEXEC)
> setpgid (POSIX_SPAWN_SETPGROUP)
> drop euid, egid (POSIX_SPAWN_RESETIDS)
> sigmask, default sighandlers (POSIX_SPAWN_SETSIGMASK, POSIX_SPAWN_SETSIGDEF)
> sched param/policy (POSIX_SPAWN_SETSCHEDPARAM, POSIX_SPAWN_SETSCHEDULER)
>
> but not these:
>
> setsid
> setuid, setgid, setgroups
> chdir
> chroot
> rlimits
> enable ptrace
> ioctl, setctty/noctty
> prctl, parent death signal
> (maybe others..)
See http://austingroupbugs.net/view.php?id=603
It's possible this would be added if the effort is put into it. I'm
unsure how desirable that is. Basically the number of things one might
want to set in the child will continue to grow over time, so the ideal
situaion would be to have a callback, but that would be incompatible
with in-kernel implementations of posix_spawn (I think NetBSD has one
now) and would be generally unsafe anyway (it would be difficult to
specify what you could safely call from the callback). So if
additional attributes are added, there will be a maintenance burden.
Note that among the above list, several items (chroot, setgroups,
ptrace, parent death signal, ...) are outside the scope of POSIX so
they would not get added.
It would be nice if the shell just had a way to perform these actions
efficiently; then you could call posix_spawn with:
"sh", "-c", "set_attrs_cmd && exec \"$@\"", "cmd", "arg1", ..., (void*)0
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
