Contributed by tj on from the now-even-shinier dept.
CVSROOT: /cvs
Module name: ports
Changes by: robert@cvs.openbsd.org 2016/01/06 14:46:44
Modified files:
www/chromium : Makefile
www/chromium/patches: patch-base_sys_info_openbsd_cc
patch-content_content_common_gypi
patch-content_gpu_gpu_main_cc
patch-content_renderer_renderer_main_platform_delegate_linux_cc
Added files:
www/chromium/patches:
patch-content_common_sandbox_init_openbsd_cc
patch-content_common_sandbox_init_openbsd_h
patch-content_ppapi_plugin_ppapi_thread_cc
patch-content_renderer_renderer_main_cc
patch-content_utility_utility_main_cc
patch-device_battery_battery_gyp
Log message:
pledge(2) the chromium processes;
The renderer, gpu, plugin and utility processes are now using pledge(2)
Unfortunately the GPU process only requires an rpath pledge because of
Mesa trying to parse two configuration files, /etc/drirc and ${HOME}/.drirc
So currently the GPU process will use an rpath pledge in the next
week or so so that people can test, but this situation has to be
resolved because it is not acceptable that a mostly unused configuration
file is being parsed from a library and that stops us from using less
pledges and thus disallowing the GPU process to have read access
to the filsystem ... like your ssh keys.
Chromium is one of the first bigger ports to receive the pledge treatment, following some compression tools a few months ago. Note that you will need a recent kernel for this to work. Stay tuned for further improvements in this space!
UPDATE: the rpath pledge has been removed.
(Comments are closed)
By Anonymous Coward (79.247.189.118) on
I ask because it would change some concepts.
Comments
By Theo de Raadt (199.185.136.55) on
>
> I ask because it would change some concepts.
The patch places tiny pledge calls at the intended locations in the Chrome sandbox model. There probably is no technical reason against upstreaming it. I get the feeling you didn't read the patch.