search for: export_name_len

...security reasons, be careful about: + * + * - Returning more data than is sent by the client. + * + * - Inputs that result in unbounded output. + * + * - Inputs that could hang, crash or exploit the server. + */ +static void * +reflection_open (int readonly) +{ + const char *export_name; + size_t export_name_len; + struct handle *h; + + h = malloc (sizeof *h); + if (h == NULL) { + nbdkit_error ("malloc: %m"); + return NULL; + } + + switch (mode) { + case MODE_EXPORTNAME: + case MODE_BASE64EXPORTNAME: + export_name = nbdkit_export_name (); + if (export_name == NULL) { + fre...

Proposal for new APIs to list exports. The general shape of the API can probably best be seen from the examples/list-exports.c example. Rich.

...y); + len = be32toh (h->sbuf.or.option_reply.replylen); + switch (reply) { + case NBD_REP_SERVER: + /* Got one export. */ + if (len > maxpayload) + debug (h, "skipping too large export name reply"); + else { + elen = be32toh (h->sbuf.or.payload.server.server.export_name_len); + if (elen > len - 4) { + set_error (0, "invalid export length"); + SET_NEXT_STATE (%.DEAD); + return 0; + } + /* Copy the export name to the handle list. */ + name = strndup (h->sbuf.or.payload.server.str, elen); + if (name == NULL) {...

This series is based on my blog posting here: https://rwmj.wordpress.com/2019/09/13/nbdkit-supports-exportnames/ It depends on the fix for realloc: https://www.redhat.com/archives/libguestfs/2019-September/thread.html#00103 This series adds a fun plugin, and also an semi-related feature I've long thought to be desirable. You can consider patches 1 & 4, and patches 2 & 3 as forming

...const char *data, size_t len, struct handle *ret) * - Inputs that result in unbounded output. * * - Inputs that could hang, crash or exploit the server. + * + * - Leaking host information (eg. paths). */ static void * reflection_open (int readonly) { const char *export_name; size_t export_name_len; + struct sockaddr_storage addr; + socklen_t addrlen; struct handle *h; h = malloc (sizeof *h); @@ -189,6 +268,15 @@ reflection_open (int readonly) return h; } + case MODE_ADDRESS: + addrlen = sizeof addr; + if (nbdkit_peer_name ((struct sockaddr *) &addr, &ad...

....option_reply.replylen); > + switch (reply) { > + case NBD_REP_SERVER: > + /* Got one export. */ > + if (len > maxpayload) > + debug (h, "skipping too large export name reply"); > + else { > + elen = be32toh (h->sbuf.or.payload.server.server.export_name_len); > + if (elen > len - 4) { > + set_error (0, "invalid export length"); > + SET_NEXT_STATE (%.DEAD); > + return 0; > + } > + /* Copy the export name to the handle list. */ > + name = strndup (h->sbuf.or.payload.server.str...

An incremental improvement on top of listing exports. I still think it's worth experimenting with revisiting how our API for list mode should actually work [1] (so that we can reuse a single connection for both grabbing the list and finally using NBD_OPT_GO), but this change was easier to whip together while still thinking about that. [1]

Necessary when writing a client that wants to avoid unnecessary EINVAL errors from sending unaligned requests. At some point, we may want to add synchronous convenience API wrappers that do request splitting or read-modify-write to obey server constraints while still appearing to the library client as accepting any possible request. But such a wrapper should only be synchronous and not copied to

...t;); + printf ("info_base64=yes\n"); #endif } @@ -228,7 +228,7 @@ handle_address (struct sockaddr *sa, socklen_t addrlen, * - Leaking host information (eg. paths). */ static void * -reflection_open (int readonly) +info_open (int readonly) { const char *export_name; size_t export_name_len; @@ -286,7 +286,7 @@ reflection_open (int readonly) /* Close the per-connection handle. */ static void -reflection_close (void *handle) +info_close (void *handle) { struct handle *h = handle; @@ -298,7 +298,7 @@ reflection_close (void *handle) /* Get the disk size. */ static int64_t -...

...f (len >= maxpayload) debug (h, "skipping too large export name reply"); else { + /* server.str is oversized for trailing NUL byte convenience */ + h->sbuf.or.payload.server.str[len - 4] = '\0'; elen = be32toh (h->sbuf.or.payload.server.server.export_name_len); if (elen > len - 4 || elen > NBD_MAX_STRING || len - 4 - elen > NBD_MAX_STRING) { @@ -85,42 +90,23 @@ STATE_MACHINE { SET_NEXT_STATE (%.DEAD); return 0; } - /* Copy the export name and description to the handle list. */ - exp.name = st...

...f (len >= maxpayload) debug (h, "skipping too large export name reply"); else { + /* server.str is oversized for trailing NUL byte convenience */ + h->sbuf.or.payload.server.str[len - 4] = '\0'; elen = be32toh (h->sbuf.or.payload.server.server.export_name_len); if (elen > len - 4 || elen > NBD_MAX_STRING || len - 4 - elen > NBD_MAX_STRING) { @@ -85,42 +90,23 @@ STATE_MACHINE { SET_NEXT_STATE (%.DEAD); return 0; } - /* Copy the export name and description to the handle list. */ - exp.name = st...

v1 was: https://www.redhat.com/archives/libguestfs/2019-September/thread.html#00361 v2: - Adds a patch to rename the reflection plugin to the info plugin. - Adds tests. Rich.

This is a subset of my v2 posting, but limited to just the NBD_OPT_LIST handling. The biggest change since v2 is the addition of added unit testing in all four language bindings (C, python, ocaml, golang). The tests require nbdkit built from git on PATH, and may not be entirely idiomatic, but I at least validated that they catch issues (for example, adding an exit statement near the end of the

Well, I'm not quite done (I still want to get nbdinfo to work on a single nbd connection for all cases when reading the heads of the file is not required), but I'm happy with patches 1-11, and 12-13 show where I'm headed for getting NBD_OPT_INFO to work. Posting now to see if some of the earlier patches are ready to commit while I continue working on the latter half. Eric Blake (13):