[Libguestfs] [nbdkit PATCH v6] vddk: Add re-exec with altered environment

[Eric Blake]

On 2/18/20 4:48 AM, Richard W.M. Jones wrote:

>> Since VDDK only runs on Linux, we can assume the presence of
>> /proc/self/{exe,cmdline}, and parse off everything we need (provided
>> nbdkit didn't muck with argv[], which we just fixed) to recursively
>> exec with a munged environment that still has enough breadcrumbs to
>> undo the munging.
>>
>> This patch does not quite set LD_LIBRARY_PATH correctly in all cases
>> (since vddk expects libdir= to point to vmware-vix-disklib-distrib/,
>> but LD_LIBRARY_PATH to vmware-vix-disklib-distrib/lib64), but that
>> will be cleaned up in the next patch; in the meantime, the re-exec in
>> this patch fires but has no ill effects.
>>

>> @@ -72,7 +73,8 @@ int vddk_debug_extents;
>>   #define VDDK_MINOR 1
>>
>>   static void *dl = NULL;                    /* dlopen handle */
>> -static int init_called = 0;                /* was InitEx called */
>> +static bool init_called = false;           /* was InitEx called */
>> +static char *reexeced = false;             /* did libdir require reexec */
> 
> I guess this works, but is "NULL" better than "false"?

Rebasing snafu - I originally started with bool reexeced, then realized 
that I need to be smarter about what prefix to strip off of 
LD_LIBRARY_PATH (as pointed out above, we generally want "$libdir/lib64" 
rather than bare "$libdir" as the LD_LIBRARY_PATH entry, since 
VixDiskLib_InitEx() asks for libdir).  Next I added a second config 
parameter (one bool, one the string to strip), got it working, then 
realized I could merge it back into one variable (the string to strip 
behaves as the bool), but forgot to change the initializer to match.

As it is, C guarantees that all static variables are 0-initialized, so = 
NULL, = 0, and = false are all redundant in this section of the file.

> 
>> +  /* If load_library caused a re-execution with an expanded
>> +   * LD_LIBRARY_PATH, restore it back to its original contents.
>> +   * dlopen uses the value of LD_LIBRARY_PATH cached at program
>> +   * startup; our change is for the sake of child processes (such as
>> +   * --run) to see the same environment as the original nbdkit saw
>> +   * before re-exec.
>> +   */
> 
> Could we pass the original LD_LIBRARY_PATH on the command line too?

Yes, that's an option. Linux in general allows long command lines, so 
we're unlikely to run into command-line length limits by doing so, and 
having the full original LD_LIBRARY_PATH makes it easier to replace the 
extended one.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org