[dm-devel] [PATCH V3 1/3] multipath-tools: Increase MAX_REPLY_LEN.
Gris Ge
fge at redhat.com
Mon Jul 4 09:11:46 UTC 2016
On Mon, Jul 04, 2016 at 08:05:19AM +0200, Hannes Reinecke wrote:
> On 07/02/2016 02:25 AM, Gris Ge wrote:
> > On Fri, Jul 01, 2016 at 04:46:53PM +0200, Hannes Reinecke wrote:
> >>> -#define MAX_REPLY_LEN 65536
> >>> +#define MAX_REPLY_LEN 10485760
> >>> +/* ^ 10 MiB, enough for 'show maps json' command with 10k paths which
> >>> + * requires about 8 MiB */
> >>>
> >>>
> >> Huh.
> >> Can't say I like it. The limit is pretty much self-imposed, so I'd
> >> rather bite the bullet and make it size-independent.
> >>
> >> Cheers,
> >>
> >> Hannes
> >> --
> >> Dr. Hannes Reinecke Teamlead Storage & Networking
> >
> > Hi Hannes Reinecke,
> >
> > How about limit the input command string size and let multipathd
> > output size-independent?
> >
> Hmm?
> We already know the size of the input (we're getting it from the
> commandline, after all). So there's no need to arbitrary limit
Not exactly, malicious IPC client application using their own socket
client implementation could send something like:
999999999999999fake command
which will lead multipathd daemon to allocate a big chunk of memory.
Even with legal IPC client library libmpathcmd, IPC client could send
a really string to daemon.
I reworked this patch to prevent this.
Meanwhile since we don't have IPC socket user ID check, above
malicious command does not require root privilege(will fix in next
week).
> anything here; we know exactly how much memory we need to allocate.
> It's just for the _output_ where we need to be careful, as we need
> to ensure that we don't allocate insane amount of memory in the
> daemon nor in the client.
On the contrary, if multipathd daemon output a insane mount of memory,
it should be a bug of multipathd daemon, rather than libmpathcmd.
Data from multipathd to IPC client[1] should be trusted and unlimited,
while data from IPC client to multipathd should be limited to
small size(let's say 255 is enough).
> So for the output we should look at implementing some sort of
> chunked response; maybe having a 4k transmit buffer, and adding a
> status bit in the CLI response instructing the client to keep on
> reading. Or something like that.
>
> Cheers,
>
> Hannes
> --
> Dr. Hannes Reinecke Teamlead Storage & Networking
[1]: 'multipathd -k' is IPC client also.
--
Gris Ge
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20160704/395153b3/attachment.sig>
More information about the dm-devel
mailing list