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