On Tue, May 09, 2023 at 08:56:47AM +0200, Laszlo Ersek wrote:
On 5/8/23 23:33, Richard W.M. Jones wrote:
On Mon, May 08, 2023 at 08:54:48AM +0200, Laszlo Ersek wrote:
On 5/7/23 12:43, Richard W.M. Jones wrote:
This is not secure so should not be used routinely. Also we do not attempt to filter environment variables, so even ones containing multiple lines or special characters are all sent to nbdkit_debug.
The reason for adding this is to allow for debugging the new nbd_set_socket_activation_name(3) API added in libnbd 1.16. --- docs/nbdkit.pod | 10 ++++++++++ server/main.c | 28 ++++++++++++++++++++++++++++ 2 files changed, 38 insertions(+)
diff --git a/docs/nbdkit.pod b/docs/nbdkit.pod index 83cf6a11c..22350cc08 100644 --- a/docs/nbdkit.pod +++ b/docs/nbdkit.pod @@ -619,6 +619,16 @@ are numerous and not usually very interesting. S<I<-D nbdkit.backend.controlpath=0>> suppresses the non-datapath commands (config, open, close, can_write, etc.)
+=item B<-D nbdkit.environ=1> + +(not Windows) + +Print nbdkit's environment variables in the debug output at start up. +This is insecure because environment variables may contain both +sensitive and user-controlled information, so it should not be used +routinely. But it is useful for tracking down problems related to +environment variables. + =item B<-D nbdkit.tls.log=>N
Enable TLS logging. C<N> can be in the range 0 (no logging) to 99. diff --git a/server/main.c b/server/main.c index 1df5d69ac..7b6adc3cc 100644 --- a/server/main.c +++ b/server/main.c @@ -210,6 +210,26 @@ dump_config (void) #endif }
+#ifndef WIN32 + +/* -D nbdkit.environ=1 to dump the environment at start up. */ +NBDKIT_DLL_PUBLIC int nbdkit_debug_environ; + +#ifndef HAVE_ENVIRON_DECL +extern char **environ; +#endif + +static void +dump_environment (void) +{ + size_t i; + + for (i = 0; environ[i]; ++i) + nbdkit_debug ("%s", environ[i]); +} + +#endif /* !WIN32 */ + int main (int argc, char *argv[]) { @@ -662,6 +682,14 @@ main (int argc, char *argv[]) /* Check all debug flags were used, and free them. */ free_debug_flags ();
+#ifndef WIN32 + /* Dump the environment if asked. This is the earliest we can do it + * because it uses a debug flag. + */ + if (nbdkit_debug_environ && verbose) + dump_environment (); +#endif + if (help) { struct backend *b;
I was surprised not to see any assignment to the new global variable, but then I found "server/debug-flags.c"; that's some serious wizardry.
With the side effect, as it turns out, that it's very hard to implement for language plugins. Rust is fine. OCaml can be done by adding a C object to the link. Other languages, not really :-(
Hm. I didn't even realize it was being done like this for plugins' sake. I assumed it was there to avoid boilerplate code.
Yes it's there to avoid boilerplate code. You can create a debug variable in a plugin very simply by exporting a symbol with the <pluginname>_debug_<name> pattern.
I figure an alternative would be for -D to stash the flags in a dictionary (or list) in the main program, and then each plugin / filter could access that data structure (or even get a reference to it in (one of) the entry point function(s)).
We can't really change how it works now as it is baked into the ABI. v2 coming up ... Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v