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