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
signature.asc
Description: PGP signature
-- dm-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/dm-devel
