Are there any implications for sandboxing on the fork vs exec ? I don't want us to paint ourselves in a corner when we implement the sandbox.
On Feb 5, 9:57 am, Rahul Kuchhal <[email protected]> wrote: > If file structure on Linux is anywhere like Windows than the shared library > (chrome.dll on Windows) would be versioned (the dll is kept inside a version > directory on Windows) but the executable itself (chrome.exe) will always > live at the same place. > On Linux are we going to allow Chrome updates to happen while Chrome is > running? In this is what we are aiming for forking sounds great since we > will end up using the same exe version and this should work as long as we > know which shared library we are using with it. > > On Thu, Feb 5, 2009 at 9:33 AM, Dan Kegel <[email protected]> wrote: > > > Firefox behaves terribly upon update on Linux because > > they didn't bother even trying to make distro updates > > work well, and everybody uses distro packages for Firefox. > > Let's avoid this same problem on Chrome for Linux. > > Does that sound like a reasonable goal? We're > > early enough in the port that it might not be too > > hard to bake that feature in. > > > What would it take to survive all our files changing > > out from under us? I imagine it would suffice to: > > > 1) open all the files we're going to need early, > > and keep the handles around for when we need them > > > 2) for our own executables, don't exec, only fork. > > That would mean using a zygote, i.e. at startup time, > > fork before creating any threads, and have the initial > > instance just be a factory for anybody who needs another > > instance of that executable. > > > Is that practical, and did I miss anything? > > - Dan --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
