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

ipc/ipc_channel_posix.h

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #ifndef IPC_IPC_CHANNEL_POSIX_H_
 #define IPC_IPC_CHANNEL_POSIX_H_
 
 #include "ipc/ipc_channel.h"
 
 #include <sys/socket.h>  // for CMSG macros
@@ skipping 156 matching lines @@
   base::ScopedFD remote_fd_pipe_;
 #endif
 
   // The "name" of our pipe.  On Windows this is the global identifier for
   // the pipe.  On POSIX it's used as a key in a local map of file descriptors.
   std::string pipe_name_;
 
   // 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
   // data (in the case of READWRITE), and are processed in FIFO here.
   // NOTE: The implementation assumes underlying storage here is contiguous, so
   // don't change to something like std::deque<> without changing the
   // implementation!
   std::vector<int> input_fds_;
 
 
@@ skipping 14 matching lines @@
   // If non-zero, overrides the process ID sent in the hello message.
   static int global_pid_;
 #endif  // OS_LINUX
 
   DISALLOW_IMPLICIT_CONSTRUCTORS(ChannelPosix);
 };
 
 }  // namespace IPC
 
 #endif  // IPC_IPC_CHANNEL_POSIX_H_