Hi Nick, SandboxBroker::AddHandleToShare was added to add the handles to the sandbox policy, before it was realised that we'd need to do this for the non-sandboxed process launch as well, hence LaunchOptions::handles_to_inherit.
I think we should change [1] to pass the LaunchOptions and then use them within SandboxBroker::LaunchApp to add the handles to the policy and get rid of SandboxBroker::AddHandleToShare. Cheers, Bob [1] https://searchfox.org/mozilla-central/rev/d03ad8843e3bf2e856126bc53b0475c595e5183b/ipc/glue/GeckoChildProcessHost.cpp#1046 On Wednesday, 14 February 2018 07:02:43 UTC, Nicholas Nethercote wrote: > Hi, > > When a content process is started, a bunch of pref values are sent via > some -intPrefs/-boolPrefs/-stringPrefs arguments on the command line. This > is > ugly and limiting and causes multiple problems, so I'd like to find a > different > way to send this data. > > The use case is pretty simple, because it's one way data transfer. The > important thing is that it must happen very early, i.e. before the normal > IPC > mechanism gets going. > > I figured shared memory would be a reasonable way to do this, something like > the following. > > - The parent sets up a shared memory segment, and writes some data to it. > > - The parent spawns the child, and passes identifying information about the > shared memory segment to the child (e.g. via the command line). > > - The child gets the shared memory segment identifer, uses it to open the > segment, and reads the data. > > - The child disposes of the shared memory segment. > > At first I tried using NSPR's shared memory functions, but they're not used > anywhere else in Firefox, and they have bugs, and shmget() is blocked by the > Linux sandbox. > > So then I tried using base::SharedMemory instead, from > ipc/chromium/src/base/shared_memory.h, basically like this: > > Parent: > SharedMemory shm; > shm.Create(name, size); > shm.Open(); > shm.Map(); > char* p = shm.memory(); > ... write data to p ... > ... launch child process, passing `name` via cmdline ... > shm.Unmap(); // done automatically when shm is destroyed > shm.Close(); // done automatically when shm is destroyed > > Child: > ... get `name` from the command line... > SharedMemory shm; > shm.Open(name); > shm.Map(); > char* p = shm.memory(); > ... read data from p ... > shm.Delete(); // this is a no-op on Windows > shm.Unmap(); // done automatically when shm is destroyed > shm.Close(); // done automatically when shm is destroyed > > This works fine on Unix. If the shared memory file is closed by the parent > before it's opened by the child, that's ok, because it persists until it is > explicitly deleted. > > But it doesn't work on Windows. On Windows Delete() does nothing. Instead, a > file mapping object is auto-deleted when its refcount falls to zero. So if > the > parent calls Close() before the child calls Open() -- which happens in > practice -- then the file mapping object is auto-deleted and the child > Open() > fails. > > If I change the parent to heap-allocate `shm` so it's not auto-destroyed at > the > end of the function, things work out, but we'll end up with leaks: the > SharedMemory object, opened file view, the handle, and the file mapping will > all leak. > > I then tried using SharedMemory::ShareToProcess(), but that requires that > the > child process already exist and the parent has its PID, which is a pain. > > I then found this blog post from Raymond Chen: > https://blogs.msdn.microsoft.com/oldnewthing/20031211-00/?p=41543 > > It describes exactly what I want, but it requires using the bInheritHandle > parameter, which base::SharedMemory doesn't do. I could change it to do so, > but > then it looks like I'd need to deal with I then found > LaunchOptions::handles_to_inherit as well... and at this point I figure it's > worth asking for help! > > Does anybody have suggestions about the best way to do this? Thanks. > > Nick _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
