[libvirt] PATCH: 4/5: Support daemonizing child & env variables

Jim Meyering jim at meyering.net
Tue Aug 19 21:10:49 UTC 2008


"Daniel P. Berrange" <berrange at redhat.com> wrote:
> On Tue, Aug 19, 2008 at 10:51:29PM +0200, Jim Meyering wrote:
>> "Daniel P. Berrange" <berrange at redhat.com> wrote:
>> > Some of the existing usage of fork/exec in libvirt is done such that the
>> > child process is daemonized. In particular the libvirt_proxy and the
>> > auto-spawned  libvirtd for qemu:///session. Since we want to switch these
>> > to use virExec, we need to suport a daemon mode.
>> >
>> > This patch removes the two alternate virExec and virExecNonBlock functions
>> > and renames the internal __virExec to virExec. It then gains a 'flags'
>> > parameter which can be used to specify non-blocking mode, or daemon mode.
>> >
>> > We also add the ability to pass in a list of environment variables which
>> > get passed on to execve(). We also now explicitly close all file handles.
>> > Although libvirt code is careful to set O_CLOSEXEC on all its file handles,
>> > in multi-threaded apps there is a race condition between opening a FD and
>> > setting O_CLOSEXEC. Furthermore, we can't guarentee that all applications
>> > using libvirt are careful to set O_CLOSEXEC. Leaking FDs to a child is a
>> > potential security risk and often causes SELinux AVCs to be raised. Thus
>> > explicitely  closing all FDs is a important safety net.
>>
>> How about closing those FDs in the child instead, right after the fork?
>> Then, if a virExec caller has an open socket or file descriptor,
>> it won't be closed behind its back.
>
> This is being done after a fork(). The diff context in this patch is
> a little misleading. The fork() shown here is the 2nd optional fork() done
> in daemon mode. The first fork() is higher up before we close the FDs.

I should have known.  Next time I'll review with the full context.
ACK, then.




More information about the libvir-list mailing list