similar to: [PATCH 1/2] daemon: NFC Use symbolic names in commandrvf

- add a flag to request chroot for the process, which is done only as very last (before chdir) operation before exec'ing the process in the child: this avoids using CHROOT_IN & CHROOT_OUT around command* invocations, and reduces the code spent in chroot mode - add failure checks for dup2 and open done in child, not proceeding to executing the process if they fail - open /dev/null

When the COMMAND_FLAG_FOLD_STDOUT_ON_STDERR flag is passed to command*(), indicate that as stdout=e in debugging message. --- daemon/command.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/daemon/command.c b/daemon/command.c index 73fce56..2423a4e 100644 --- a/daemon/command.c +++ b/daemon/command.c @@ -185,6 +185,7 @@ commandrvf (char **stdoutput, char **stderror,

Allows more sharing between the daemon and the inspection program. --- daemon/Makefile.am | 2 + daemon/cleanups.c | 80 ++++++++++ daemon/cleanups.h | 47 ++++++ daemon/command.c | 436 +++++++++++++++++++++++++++++++++++++++++++++++++++++ daemon/command.h | 41 +++++ daemon/daemon.h | 47 +----- daemon/guestfsd.c | 392 ----------------------------------------------- po/POTFILES

On Wed, Dec 02, 2015 at 02:00:57PM +0100, Pino Toscano wrote: > - add a flag to request chroot for the process, which is done only as > very last (before chdir) operation before exec'ing the process in the > child: this avoids using CHROOT_IN & CHROOT_OUT around command* > invocations, and reduces the code spent in chroot mode > - add failure checks for dup2 and open

daemon.c does just a chroot, without chdir. The result is that pwd does not work correctly (it causes fs/dcache.c:prepend_unreachable() to add the unreachable string). A workaround is to add "cd /" before each sh command. ><fs> mount /dev/sda2 / ><fs> sh "cd / ; chroot / ; /bin/pwd" / ><fs> sh "/bin/pwd" (unreachable)/ ><fs> sh

For background on this change, see: https://rwmj.wordpress.com/2015/12/06/inspection-now-with-added-prolog/ v2 was previously posted here: https://www.redhat.com/archives/libguestfs/2015-December/msg00038.html To test this patch series on a real guest, you can do: $ ./run guestfish -v -x -a /var/tmp/centos-6.img ><fs> run ><fs> debug sh "guestfs-inspection

This is a more working version. Inspection (partially) succeeds on a real guest this time :-) You can test it out on a real guest (in this case, a CentOS disk image located at /tmp/centos-6.img) by doing: $ ./run guestfish -v -x -a /tmp/centos-6.img ><fs> run ><fs> debug sh "guestfs-inspection --verbose" which will print lots of debugging, and at the end the

On Sun, Aug 18, 2013 at 02:29:15PM +0200, Olaf Hering wrote: > > daemon.c does just a chroot, without chdir. The result is that pwd does not > work correctly (it causes fs/dcache.c:prepend_unreachable() to add the > unreachable string). A workaround is to add "cd /" before each sh command. > > ><fs> mount /dev/sda2 / > ><fs> sh "cd / ; chroot

When executing a command, we temporarily chroot, fork and exec the command, then chroot back. We intentionally don't chdir in the parent process so that we can 'jailbreak' the chroot later. However, this has the effect that commands are executed with a current working directory which is outside the current root. This unusual state can cause errors in executed commands which don't

One more after this, and "make syntax-check" will pass once more. >From 5c360133c0d4e09531d432abca0629798b87ff39 Mon Sep 17 00:00:00 2001 From: Jim Meyering <meyering at redhat.com> Date: Mon, 9 Nov 2009 15:14:53 +0100 Subject: [PATCH libguestfs] indent with spaces, not TABs * HACKING: Expand indentation TABs. * configure.ac: Likewise. * daemon/daemon.h: Likewise. *

I ran the Coverity static analyzer[1] on libguestfs, and fixed many errors as a result. Coverity found some errors in gnulib, but it doesn't seem to be worth following those up since the version of gnulib we are using is so old. There are a couple more errors (possibly 1 false-positive) which I'm going to send in a separate email. BTW all the errors found by Coverity were in the daemon

http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=395 The guest domain crashed during the routine daily tests that I ran. Machine: IBM ThinkCentre, 1GB of RAM with FC3 based setup. Xen build, PAE enabled using changeset: 7701:abbe3df33774 [root@thinkcentre-dom0 xen-unstable.hg]# cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 3

When running commands in the mounted guest (using the "command" API, and APIs based on it), provide the /dev/null from the appliance as open fd for stdin. Commands usually assume stdin is open if they didn't close it explicitly, so this should avoid crashes or misbehavings due to that. --- daemon/command.c | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-)

On Thu, Nov 19, 2015 at 05:38:25PM +0100, Pino Toscano wrote: > When running commands in the mounted guest (using the "command" API, and > APIs based on it), provide the /dev/null from the appliance as open fd > for stdin. Commands usually assume stdin is open if they didn't close > it explicitly, so this should avoid crashes or misbehavings due to that. This does not

On Tue, Dec 01, 2015 at 04:16:57PM +0100, Pino Toscano wrote: > On Tuesday 01 December 2015 15:59:56 Mateusz Guzik wrote: > > I would argue that /dev has to be at least partially populated for anything > > that gets executed in the chroot. At the very least special nodes like null, > > zero and {u,}random are needed. > > We do not assume anything about guests, which

Hi everyone, I was trying the new send/receive feature today but can''t make it work. These are the commands I was using: btrfs subvol snap -r /mnt/data1/@downloads/ /mnt/data1/snapshots/testsnap btrfs send /mnt/data1/snapshots/testsnap | btrfs receive /mnt/data1/snapshots/testreceive/ This command never finishes. A ''ls /mnt/data1/snapshots/testreceive/ '' never

The warnings in daemon were aggravating and risky for development (too easy to miss new ones) so I spent some time last week and today working on removing them. The first patch gets us down to almost no warnings with the original -Wall setting. That was by far the hardest part. Once I'd done that, I enabled nearly all of gcc's warnings via gnulib's warnings and manywarnings modules

On Friday, 14 July 2017 15:39:10 CEST Richard W.M. Jones wrote: > .gitignore | 6 +- > Makefile.am | 2 +- > common/mlutils/Makefile.am | 4 - > daemon/Makefile.am | 103 +++++++++++++++++++++++-- > daemon/chroot.ml | 85 +++++++++++++++++++++ > daemon/chroot.mli | 35 +++++++++ > daemon/daemon-c.c |

These two patches are probably not completely independent, but separating them is a lot of work. With *both* patches applied, all the tests and extra-tests pass. That's no guarantee however that there isn't a mistake, so I don't think this patch is a candidate for the 1.16 branch, until it's had a lot more testing in development. Rich.

Hi all, I'm having a bit of a problem with a CentOS box. It ocasionally crashes/freezes. I configured to send all kernel logging to a remote box so I've been able to catch one kernel crash: May 12 15:34:18 ioana.slack.i kernel: ------------[ cut here ]------------ May 12 15:34:18 ioana.slack.i kernel: kernel BUG at arch/i386/kernel/ldt.c:46! May 12 15:34:18 ioana.slack.i kernel: