Make IPC::Channel buffers stack based and secure against growth

ipc/ipc_channel_posix.h

Index: ipc/ipc_channel_posix.h
diff --git a/ipc/ipc_channel_posix.h b/ipc/ipc_channel_posix.h
index a65283d3beace7fafdd02f9c74b9acb68ad84b96..58c5a058734aa122d43282e255ef50c0e42e7e50 100644
--- a/ipc/ipc_channel_posix.h
+++ b/ipc/ipc_channel_posix.h
@@ -174,25 +174,17 @@ class IPC_EXPORT ChannelPosix : public Channel,
   // Messages to be sent are queued here.
   std::queue<Message*> output_queue_;
 
-  // We assume a worst case: kReadBufferSize bytes of messages, where each
-  // message has no payload and a full complement of descriptors.
-  static const size_t kMaxReadFDs =
-      (Channel::kReadBufferSize / sizeof(IPC::Message::Header)) *
-      MessageAttachmentSet::kMaxDescriptorsPerMessage;
-
-  // Buffer size for file descriptors used for recvmsg. On Mac the CMSG macros
-  // don't seem to be constant so we have to pick a "large enough" value.
-#if defined(OS_MACOSX)
-  static const size_t kMaxReadFDBuffer = 1024;
-#else
-  static const size_t kMaxReadFDBuffer = CMSG_SPACE(sizeof(int) * kMaxReadFDs);
-#endif
-
-  // Temporary buffer used to receive the file descriptors from recvmsg.
-  // Code that writes into this should immediately read them out and save
-  // them to input_fds_, since this buffer will be re-used anytime we call
-  // recvmsg.
-  char input_cmsg_buf_[kMaxReadFDBuffer];
+  // Worst case for file descriptors would be : kReadBufferSize bytes
+  // of messages, where each message has no payload and a full
+  // complement of descriptors:
+  // CMSG_SPACE(sizeof(int) *
+  //            (Channel::kReadBufferSize / sizeof(IPC::Message::Header)) *
+  //            MessageAttachmentSet::kMaxDescriptorsPerMessage)
+  //
+  // If we allocate memory for that in recvmsg we would waste hundreds
+  // of KB. Instead we note that we will only send file descriptors

[Mark Seaborn, 2015/05/06 17:50:16]

This assumption seems rather risky to me, because it breaks composability: 
Sending many FDs in one IPC message will work, and sending many IPC messages
will work, but doing both together (with many FDs in each message) can fail.

What's worse is that whether this works depends on process scheduling.  If the
receiving process's recvmsg() call gets scheduled when a few messages have been
queued up in the socket's buffer, it will work, but if the recvmsg() call gets
scheduled later when more messages have been queued up, it will fail.

It seems less risky to revert back to kMaxDescriptorsPerMessage = 7, as proposed
in https://codereview.chromium.org/1127913002/.

+  // occasionally and use a reasonable buffer of 8 KB.
+  static const size_t kMaxReadFDBuffer = 8192;
 
   // File descriptors extracted from messages coming off of the channel. The
   // handles may span messages and come off different channels from the message