"Daniel P. Berrange" <berrange@xxxxxxxxxx> wrote: > On Tue, Aug 19, 2008 at 10:51:29PM +0200, Jim Meyering wrote: >> "Daniel P. Berrange" <berrange@xxxxxxxxxx> 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. -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list