search for: nbdkit_is_tl

...iate content for a --tls=on server, since TLS is optional according to whether the client has authenticated. For internal code and filters, this means adding a new parameter; the sh plugin can do likewise. For plugins, we can't add a parameter until the V3 protocol, so in the meantime, we add nbdkit_is_tls(), even though it will be deprecated alongside nbdkit_export_name() when we do get to V3. Signed-off-by: Eric Blake <eblake@redhat.com> --- docs/nbdkit-filter.pod | 12 ++++++++---- docs/nbdkit-plugin.pod | 32 +++++++++++++++++++++++++++---- docs/nbdkit-tls.pod...

Patch 3 still needs tests added, but it is at least working from my simple command line tests. Eric Blake (3): server: Implement nbdkit_is_tls for use during .open server: Expose final thread_model to filter's .get_ready tlsdummy: New filter docs/nbdkit-filter.pod | 21 +- docs/nbdkit-plugin.pod | 34 ++- docs/nbdkit-tls.pod | 8 +- filters/log/nbdkit-log-fil...

...> + return nbdkit_main (argc, argv); > +} > diff --git a/server/nbdkit.syms b/server/nbdkit.syms > index a67669b7..a516cc0f 100644 > --- a/server/nbdkit.syms > +++ b/server/nbdkit.syms > @@ -54,6 +54,7 @@ > nbdkit_extents_new; > nbdkit_get_extent; > nbdkit_is_tls; > + nbdkit_main; Do we want to export it as _nbdkit_main, to make it obvious that plugins shouldn't try calling it? That's cosmetic if you think it is worth it. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvir...

...ers/tlsdummy/tlsdummy.c diff --git a/docs/nbdkit-plugin.pod b/docs/nbdkit-plugin.pod index 6237b749..43b0f6f9 100644 --- a/docs/nbdkit-plugin.pod +++ b/docs/nbdkit-plugin.pod @@ -1478,7 +1478,9 @@ On error, C<nbdkit_error> is called and the call returns C<NULL>. A server may use C<nbdkit_is_tls> to limit which export names work until after a client has completed TLS authentication. See -L<nbdkit-tls(1)>. +L<nbdkit-tls(1)>. It is also possible to use +L<nbdkit-tlsdummy-filter(1)> to automatically ensure that the plugin +is only used with authentication. =head2 C&...

...h index e20391b8..23b44ef8 100644 --- a/include/nbdkit-plugin.h +++ b/include/nbdkit-plugin.h @@ -144,9 +144,9 @@ struct nbdkit_plugin { struct nbdkit_exports *exports); }; -extern void nbdkit_set_error (int err); -extern const char *nbdkit_export_name (void); -extern int nbdkit_is_tls (void); +extern NBDKIT_DLLEXPORT void nbdkit_set_error (int err); +extern NBDKIT_DLLEXPORT const char *nbdkit_export_name (void); +extern NBDKIT_DLLEXPORT int nbdkit_is_tls (void); #define NBDKIT_REGISTER_PLUGIN(plugin) \ NBDKIT_CXX_LANG_C...

...rgv); > >+} > >diff --git a/server/nbdkit.syms b/server/nbdkit.syms > >index a67669b7..a516cc0f 100644 > >--- a/server/nbdkit.syms > >+++ b/server/nbdkit.syms > >@@ -54,6 +54,7 @@ > > nbdkit_extents_new; > > nbdkit_get_extent; > > nbdkit_is_tls; > >+ nbdkit_main; > > Do we want to export it as _nbdkit_main, to make it obvious that > plugins shouldn't try calling it? That's cosmetic if you think it > is worth it. I was a bit in two minds about whether this API should be public or not. Could it be called by...

...and new APIs -C<nbdkit_add_export>, C<nbdkit_exports_new>, C<nbdkit_exports_free>, -C<nbdkit_exports_count>, C<nbdkit_get_export> can be used by plugins -and filters to reply to clients which want to list the exports that -the server supports (Eric Blake). - New C<nbdkit_is_tls> can be called to determine if TLS was negotiated on the connection. Plugins could use this to hide certain exports from non-authenticated/non-encrypted clients (Eric Blake). -- 2.27.0

...ely +passing it down to the next layer) it must take a copy, although +C<nbdkit_string_intern> is useful for this task. The C<exportname> and C<is_tls> parameters are provided so that filters do not need to use the plugin-only interfaces of C<nbdkit_export_name> and C<nbdkit_is_tls>. diff --git a/docs/nbdkit-plugin.pod b/docs/nbdkit-plugin.pod index 64e3197b..eaa5edba 100644 --- a/docs/nbdkit-plugin.pod +++ b/docs/nbdkit-plugin.pod @@ -744,7 +744,10 @@ unintended information. If the plugin returns C<NULL>, the client is not permitted to connect to the default exp...

...ely +passing it down to the next layer) it must take a copy, although +C<nbdkit_strdup_intern> is useful for this task. The C<exportname> and C<is_tls> parameters are provided so that filters do not need to use the plugin-only interfaces of C<nbdkit_export_name> and C<nbdkit_is_tls>. diff --git a/docs/nbdkit-plugin.pod b/docs/nbdkit-plugin.pod index 50cf991d..056b1450 100644 --- a/docs/nbdkit-plugin.pod +++ b/docs/nbdkit-plugin.pod @@ -748,7 +748,10 @@ leak unintended information. If the plugin returns C<NULL> or an invalid string (such as longer than 4096 bytes),...

More patches on the way for improving .list_exports signature and adding .export_description, but this is the promised code showing why nbdkit_string_intern is useful. Patch 4 is somewhat RFC: we could either add new API to take the boilerplate from: foo_config(const char *key, const char *value) { if (strcmp (key, "file") == 0) { CLEANUP_FREE char *tmp = nbdkit_realpath (value);

...the real main function in + * libnbdkit.so. + */ + return nbdkit_main (argc, argv); +} diff --git a/server/nbdkit.syms b/server/nbdkit.syms index a67669b7..a516cc0f 100644 --- a/server/nbdkit.syms +++ b/server/nbdkit.syms @@ -54,6 +54,7 @@ nbdkit_extents_new; nbdkit_get_extent; nbdkit_is_tls; + nbdkit_main; nbdkit_nanosleep; nbdkit_parse_bool; nbdkit_parse_int8_t; diff --git a/tests/test-nbdkit-backend-debug.sh b/tests/test-nbdkit-backend-debug.sh index 3a28b756..1533ba44 100755 --- a/tests/test-nbdkit-backend-debug.sh +++ b/tests/test-nbdkit-backend-debug.sh @@ -49,...

...t that the library creates background threads especially when accessing remote servers. New API "nbdkit_extents_aligned" is a helper function for filters that retrieves extents as needed until at least a certain range is covered (Eric Blake). New "nbdkit_is_tls" can be called to determine if TLS was negotiated on the connection. Plugins could use this to hide certain exports from non-authenticated/non-encrypted clients (Eric Blake). "nbdkit_read_password" with "password=-" will now return an error if...

...const char *def; switch (call_read (&s, &slen, args)) { case OK: return parse_exports (script, s, slen, exports); case MISSING: - return nbdkit_add_export (exports, "", NULL); + /* Match what is done for a C plugin. */ + def = sh_default_export (readonly, nbdkit_is_tls ()); + if (!def) + return 0; + return nbdkit_add_export (exports, def, NULL); case ERROR: return -1; @@ -331,6 +338,49 @@ sh_list_exports (int readonly, int default_only, } } +const char * +sh_default_export (int readonly, int is_tls) +{ + const char *method = "defau...

If you're following nbdkit development upstream you'll have seen that we are still making changes to the .list_exports and related APIs. The current .list_exports API upstream is not how it will look finally. The latest set of proposals was here: https://www.redhat.com/archives/libguestfs/2020-August/thread.html#00330 At the same time I'd like to do an nbdkit 1.22 (stable) release.

...so make it easier to express the notion of no default export (connecting to "" is an error) at the same time as listing other exports. Another consideration is that when tls=1, the choice of export to expose pre-TLS vs. post-TLS may differ, but without a call to .open yet, our just-added nbdkit_is_tls() does not fit our preferred lifecycle, so this has to be a parameter to the new .default_export. We will alter the signature of .list_exports soon; in the meantime, the bool default_only parameter is now ignored. Adding .default_export support to sh/eval is big enough for a separate patch. The...

This is a revision of my .default_export work, plus new work on .export_descriptions and a new exportname filter. I think it is now ready to check in. Things I'd still like in 1.22: - the file plugin should implement .list_exports (patch already posted, but it needs rebasing on this series) - the ext2 filter should override .list_exports when in exportname mode - the nbd plugin should be

Also available here: https://github.com/rwmjones/nbdkit/tree/2020-windows-mingw This is the port to Windows using native Windows APIs (not MSYS or Cygwin). This patch series is at the point where it basically now works. I can run the server with the memory plugin, and access it remotely using guestfish, creating filesystems and so on without any apparent problems. Nevertheless there are many

The patches following do indeed allow you to compile nbdkit.exe, but it does not actually work yet. I'm posting this experimental series more as a work in progress and to get feedback. Note this does not require Windows itself to build or test. You can cross-compile it using mingw64-* packages on Fedora or Debian, and test it [spoiler alert: it fails] using Wine. Rich.

It's been several weeks since I posted v2 (I got distracted by improving libnbd to better test things, which in turn surfaced some major memory leak problems in nbdsh that are now fixed). Many of the patches are minor rebases from v2, with the biggest changes being fallout from: - patch 2: rename nbdkit_add_default_export to nbdkit_use_default_export - overall: this missed 1.22, so update