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
_______________________________________________
Libguestfs mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/libguestfs
