On Mon, Sep 20, 2010 at 11:44:06AM +0100, Matthew Booth wrote:
When writing to a RHEV target, virt-v2v launches the libguestfs appliance with euid:egid = 36:36, which is required to write to an NFS target using root_squash. Since the update to use an febootstrap cached appliance, this causes an error on startup as the cached files are owned by root, but the cache directory is owned by 36:36. The reason for this is that execve() resets euid and egid to uid and gid respectively, so when febootstrap-supermin-helper is executed, it runs as root:root. The cache directory, however, is created by libguestfs directly without exec()ing another program, so it has the correct ownership.
This patch fixes this issue by setting real uid and gid to euid and egid respectively before exec()ing the helper program.
Turns out to be a misfeature of bash, not the exec system call. I've got a few general comments, but I will try to write an alternative patch and post that. My comments are: (1) Since febootstrap-supermin-helper -f checksum ... doesn't write to any file nor does it look in the cache directory, that whole call to popen presumably can stay as it is. That reduces the complexity of the patch considerably. Or am I missing something about that? (2) posix_spawn(3) is a better replacement for system(3). If you *omit* the POSIX_SPAWN_RESETIDS flag then it looks from a casual reading of the man page that posix_spawn won't try to change the uid or euid of the child process. As I said I will try writing an alternate patch. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora