[Libguestfs] [PATCH nbdkit 9/9] eval, sh: Define $nbdkit_safe_stdio = 0|1 in scripts.

[Eric Blake]

On 4/15/20 2:11 PM, Eric Blake wrote:

>>> Side thought: Both the eval and sh plugins already pass on all
>>> unrecognized key=value pairs through to the .config callback, and
>>> error out if the config callback returns missing.  But right now, if
>>> a script wants to set up an environment variable that will still be
>>> present to affect later calls, it has to track things itself
>>> (perhaps by having the .config callback append to $tmpdir/vars, then
>>> all other callbacks start by 'source $tmpdir/vars').  Would it make
>>> sense to reserve a special exit value from the .config callback for
>>> the case where the script wants the current key=value passed to
>>> config to be preserved to all future callbacks?  Or even state that
>>> the config callback exiting with status 2 (for missing) is NOT an
>>> error, but does the key=value preservation automatically?
>>
>> Would it be secure, given that plausibly the command line could be
>> supplied from a different place than the script.  eg. if an untrusted
>> user sets $PATH ...
> 
> Interesting thought. That makes me lean more towards a new exit value 
> (for intentional opt-in) rather than reusing status 2 (missing) as the 
> reason to drive the new behavior.

Conversely, it's just as easy to write:

foo=bar nbdkit sh script

as it is to write:

nbdkit sh script foo=bar

but the former already works (setting $foo visible to all invocations of 
script) while the latter is what we are discussing (having nbdkit set 
$foo since .config was missing).  I guess it is more a question for 
convenience when invoking nbdkit from other places (such as libnbd 
connect_command) where overriding the environment is not as easy as when 
you are directly invoking nbdkit from a shell command line.

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