[Libguestfs] [PATCH nbdkit 0/4] Reflection plugin, peer name.

[Martin Kletzander]

On Sun, Sep 15, 2019 at 03:55:41PM +0100, Richard W.M. Jones wrote:
>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 standalone patch series (but they do depend
>on each other).
>
>The fun plugin is a reflection plugin which "reflects" client
>information back to the client.  We have a few fun plugins like this
>(hello there, nbdkit-full-plugin) and normally I would push these
>without review, but in this particular case there's a specific danger
>that sending back data under control of the client might lead to a
>security problem.  I _believe_ I have avoided that pitfall, but my
>belief isn't as good as having experts review it :-)
>

Even though I am not part of that group you mentioned I had a look at it and I
could not find any issue with that; you are keeping the size returned by the
base64 decoder and other than that it is all data which should be safe as far as
I understand it.

>The new feature is nbdkit_peer_name() which returns the sockaddr of
>the peer.  It's essentially a wrapper around getpeername(2).  This

It's a pity there is no information for UNIX sockets.  Would it make sense to at
least try to get the PID (or even a command name) using at least:

  getsockopt(..., SOL_SOCKET, SO_PEERCRED, ...)

at least where SO_PEERCRED is defined?

It looks good to me.

>would allow several features to be implemented in future:
>
> - Plugins could accept or reject connections based on IP address.
>
> - Plugins could change content based on client.  (The fourth patch in
>   the series is a PoC of this implemented in the new reflection
>   plugin.)  Be cautious about combining this feature with multi-conn
>   as it's not obviously always safe to do.
>
> - Some filters could usefully modify their behaviour based on client
>   address: The TODO file currently notes that the rate filter could
>   be changed to limit traffic based on client IP.
>
>Rich.
>
>
>
>_______________________________________________
>Libguestfs mailing list
>Libguestfs at redhat.com
>https://www.redhat.com/mailman/listinfo/libguestfs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20190916/96b23f33/attachment.sig>