The installation process for a compiled chromium package seems to link the chromium plugins directions to the typical netscape browser plugins directory, e.g. plugins.ORG -> /usr/lib/nsbrowser/plugins Which would be fine if the there would not be Netscape plugins which behave badly (I thin mozplugger.so is an example) which do not appear to cause problems for Mozilla browsers but are handled poorly by chromium. Primarily due to the failure to collect zombie processes (which may be children of children), resulting in the accumulation of zombie terminated child processes which leads to a failure of fork calls to create new processes for users due to per user process limit restrictions. I have documented this in the chromium issues reports and they may eventually fix it. But in the meantime there is a problem with a chromium installation using carte-blanche the Netscape plugins. Problem #1 is as documented, the behavior of plugins which do not behave the same way in chrome that they behave in Mozillla; Problem #2 is there may be the ability to install in the plugins directory ".so" files which create inherent security vulnerabilities. Reproducible: Always Steps to Reproduce: 1.Build a current chromium release (which may be a 6-12 hour process) 2. Notice where the /usr/lib/chromium-browser/plugins symbolic link points and its contents. 3. Access URLs which depend upon such capabilities which require the invocation of plugins, FLASH and PDF being to two primary examples, but one can easily envision others. Actual Results: The programs may function effectively for a time, but may ultimately hit the process limit (at least with chrome). Expected Results: a) Programs should collect children and inherited children. This is not done in FIrefox. b) The chromium "plugins" directory should only contain links to packages which are "known" to be problematic. Indeed, it should not depend on the links in other packages -- which may not work reliably in chromium. It would be highly desirable for chromium installation create its own links which are known to be reliable.
Robert, could you report the buggy plugin behavior upstream and post the link here? Screening every plugin for every browser doesn't sound like a good idea to me. The browser should work with every correct plugin, and gracefully handle buggy ones.
Closing per comment #1.
As per the request, see the Chrome Issue #23778 esp. Comment #48. I think this problem is in regression testing (or users can fix it themselves by being careful about what is actually in the chrome plugins directory). The URL is: http://code.google.com/p/chromium/issues/detail?id=23778
