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
Attachment:
signature.asc
Description: PGP signature
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
