OLD | NEW |
(Empty) | |
| 1 // Copyright 2014 The Chromium Authors. All rights reserved. |
| 2 // Use of this source code is governed by a BSD-style license that can be |
| 3 // found in the LICENSE file. |
| 4 |
| 5 #ifndef SANDBOX_LINUX_SYSCALL_BROKER_BROKER_COMMON_H_ |
| 6 #define SANDBOX_LINUX_SYSCALL_BROKER_BROKER_COMMON_H_ |
| 7 |
| 8 #include <fcntl.h> |
| 9 #include <stddef.h> |
| 10 |
| 11 namespace sandbox { |
| 12 |
| 13 namespace syscall_broker { |
| 14 |
| 15 const size_t kMaxMessageLength = 4096; |
| 16 |
| 17 // Some flags are local to the current process and cannot be sent over a Unix |
| 18 // socket. They need special treatment from the client. |
| 19 // O_CLOEXEC is tricky because in theory another thread could call execve() |
| 20 // before special treatment is made on the client, so a client needs to call |
| 21 // recvmsg(2) with MSG_CMSG_CLOEXEC. |
| 22 // To make things worse, there are two CLOEXEC related flags, FD_CLOEXEC (see |
| 23 // F_GETFD in fcntl(2)) and O_CLOEXEC (see F_GETFL in fcntl(2)). O_CLOEXEC |
| 24 // doesn't affect the semantics on execve(), it's merely a note that the |
| 25 // descriptor was originally opened with O_CLOEXEC as a flag. And it is sent |
| 26 // over unix sockets just fine, so a receiver that would (incorrectly) look at |
| 27 // O_CLOEXEC instead of FD_CLOEXEC may be tricked in thinking that the file |
| 28 // descriptor will or won't be closed on execve(). |
| 29 const int kCurrentProcessOpenFlagsMask = O_CLOEXEC; |
| 30 |
| 31 enum IPCCommand { |
| 32 COMMAND_INVALID = 0, |
| 33 COMMAND_OPEN, |
| 34 COMMAND_ACCESS, |
| 35 }; |
| 36 |
| 37 } // namespace syscall_broker |
| 38 |
| 39 } // namespace sandbox |
| 40 |
| 41 #endif // SANDBOX_LINUX_SYSCALL_BROKER_BROKER_COMMON_H_ |
OLD | NEW |