[Libguestfs] [PATCH nbdkit 0/4] Reflection plugin, peer name.
Martin Kletzander
mkletzan at redhat.com
Mon Sep 16 06:48:32 UTC 2019
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>
More information about the Libguestfs
mailing list