Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 541218 - www-client/chromium-41.0.2272.64: displays error on all webpages when sandbox is used
Summary: www-client/chromium-41.0.2272.64: displays error on all webpages when sandbox...
Status: RESOLVED WORKSFORME
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: x86 Linux
: Normal normal (vote)
Assignee: Chromium Project
URL:
Whiteboard: ht-wanted
Keywords: PATCH
Depends on:
Blocks:
 
Reported: 2015-02-24 09:31 UTC by Maeredhel
Modified: 2015-09-25 19:45 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Accept any call to clock_gettime() in the chromium sandbox. (chromium-sandbox.patch,674 bytes, patch)
2015-02-24 20:52 UTC, Nils Holland
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Maeredhel 2015-02-24 09:31:29 UTC
This bug has been reported upstream by someone else ( https://code.google.com/p/chromium/issues/detail?id=452648 ) but this seems gentoo-related. The "Aww ... Snap" error page appears on every webpage, including on the default start page.

Reproducible: Always

Steps to Reproduce:
1. Launch chromium
2.
3.
Actual Results:  
"Aww ... Snap" error page appears

Expected Results:  
Default start page

From what I understood from the upstream bug report, some restrictions have been added to the access of clock_getres(), clock_gettime() and clock_settime() functions in the sandbox. It seems that the gentoo ebuild uses some system libraries instead of bundled ones and that these libraries access to restricted functions, causing the rendering process to fail.

Launching chromium without sandbox ( --no-sandbox option) works.

I am not sure whether this bug should concern upstream only or also gentoo. I though it would be worth mentioning here.

Just in case, here is my emerge --info 


Portage 2.2.17 (python 3.3.5-final-0, default/linux/x86/13.0/desktop/gnome, gcc-4.9.2, glibc-2.20-r2, 3.16.2-gentoo i686)
=================================================================
System uname: Linux-3.16.2-gentoo-i686-Intel-R-_Core-TM-2_Duo_CPU_P7450_@_2.13GHz-with-gentoo-2.2
KiB Mem:     3106532 total,    845124 free
KiB Swap:    2046972 total,   2046972 free
Timestamp of repository gentoo: Mon, 23 Feb 2015 12:30:02 +0000
sh bash 4.3_p33-r1
ld GNU ld (Gentoo 2.25 p1.0) 2.25
app-shells/bash:          4.3_p33-r1::gentoo
dev-java/java-config:     2.2.0::gentoo
dev-lang/perl:            5.20.2::gentoo
dev-lang/python:          2.7.9-r2::gentoo, 3.3.5-r1::gentoo, 3.4.2::gentoo
dev-util/cmake:           3.1.0::gentoo
dev-util/pkgconfig:       0.28-r2::gentoo
sys-apps/baselayout:      2.2::gentoo
sys-apps/openrc:          0.13.11::gentoo
sys-apps/sandbox:         2.6-r1::gentoo
sys-devel/autoconf:       2.13::gentoo, 2.69::gentoo
sys-devel/automake:       1.11.6-r1::gentoo, 1.15::gentoo
sys-devel/binutils:       2.25::gentoo
sys-devel/gcc:            4.9.2::gentoo
sys-devel/gcc-config:     1.8::gentoo
sys-devel/libtool:        2.4.6::gentoo
sys-devel/make:           4.1-r1::gentoo
sys-kernel/linux-headers: 3.19::gentoo (virtual/os-headers)
sys-libs/glibc:           2.20-r2::gentoo
Repositories:

gentoo
    location: /usr/portage
    sync-type: rsync
    sync-uri: rsync://rsync.gentoo.org/gentoo-portage
    priority: -1000

science
    location: /var/lib/layman/science
    masters: gentoo
    priority: 0

java-overlay
    location: /var/lib/layman/java-overlay
    masters: gentoo
    priority: 1

sunrise
    location: /var/lib/layman/sunrise
    masters: gentoo
    priority: 2

hasufell
    location: /var/lib/layman/hasufell
    masters: gentoo
    priority: 3

gamerlay
    location: /var/lib/layman/gamerlay
    masters: gentoo
    priority: 4

x-portage
    location: /usr/local/portage
    masters: gentoo
    priority: 5

ACCEPT_KEYWORDS="x86 ~x86"
ACCEPT_LICENSE="* -@EULA"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=i686 -pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/lib/libreoffice/program/sofficerc /usr/share/gnupg/qualified.txt"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c"
CXXFLAGS="-O2 -march=i686 -pipe"
DISTDIR="/usr/portage/distfiles"
FCFLAGS="-O2 -march=i686 -pipe"
FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync"
FFLAGS="-O2 -march=i686 -pipe"
GENTOO_MIRRORS="ftp://mirror.ovh.net/gentoo-distfiles/"
LANG="fr_FR.UTF-8" "
LC_ALL="fr_FR.UTF-8" "
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
MAKEOPTS="-j3"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
USE="X a52 aac acl acpi alsa berkdb bluetooth branding bzip2 cairo cdda cdr cli colord consolekit cracklib crypt cups cxx dbus dri dts dvd dvdr eds emboss encode evo exif fam firefox flac fortran gdbm gif glamor gnome gnome-keyring gnome-online-accounts gpm gstreamer gtk iconv icu introspection ipv6 jpeg lcms ldap libnotify libsecret mad mng modules mp3 mp4 mpeg nautilus ncurses nls nptl ogg opengl openmp pam pango pcre pdf png policykit ppds pulseaudio qt3support readline sdl session socialweb spell ssl startup-notification svg systemd tcpd tiff truetype udev udisks unicode upower usb vorbis wxwidgets x264 x86 xcb xml xv xvid zlib" ABI_X86="32" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="mmx mmxext sse sse2 sse3 sse4_1 ssse3" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="evdev keyboard mouse synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-minimizer nlpsolver" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_3" RUBY_TARGETS="ruby19 ruby20" USERLAND="GNU" VIDEO_CARDS="radeon" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"
Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
Comment 1 Nils Holland 2015-02-24 20:51:24 UTC
I'm the one who reported the bug to upstream! :-)

The issue seems to be that the chromium sandbox restricts access to certain clocks only via the clock_gettime() syscall, and chromium when built using Gentoo's ebuild (i.e. using various system libs) tries to access clocks which are not permitted to be accessed. This is happening for me on a fully up-to-date ~x86 system, I've also seen this confirmed on arm, but no reports on ~amd64 or anything else yet.

Probably someone has an idea how to quickly find out what's actually wrong here. I'm currently on vacation, but once I'm back home, I'm planning to find out which system library is actually trying to access which clock here, violating the sandbox rules. Doing this is actually made harder by the fact that a debug build of chromium would be nice to do this research, but trying to create a debug build has in a first attempt resulted in ld running out of address space here on ~x86. I've tried to build a dynamically linked chromium debug build as well (chromium is generelly built statically linked, also on Gentoo). A dynamic build completes successfully, but I've been unable to reproduce the bug there - a dynamically built debug chromium seemed to work without any issues for me, strangely. So, what I'm planning to do is have a closer look at the an ordinary, statically build version, even if I can't build it with debug symbols.

In the meantime, the whole issue can be worked around with using the small patch which I'll attach to this issue. This patch makes the sandbox permit any clock_gettime() call, regardless of the clk_id requested. A chromium build using this patch will not have the problem this bug report deals with. The patch might make the browser less secure ... but well, I don't think that this should really be an issue. A possibility would be for Gentoo to use this patch, at least on the x86 platform, until the real reason and a fix is found.
Comment 2 Nils Holland 2015-02-24 20:52:42 UTC
Created attachment 397442 [details, diff]
Accept any call to clock_gettime() in the chromium sandbox.
Comment 3 Maeredhel 2015-02-27 18:51:02 UTC
Thank you very much for the working patch, and for your very detailed explanations. Indeed, I don't think the patch creates a big security issue, but it would still be interesting to know which lib violates the rules. I clearly don't have the competencies to do that, but I can help you test hypothesis, if needed.
Comment 4 Paweł Hajdan, Jr. (RETIRED) gentoo-dev 2015-09-20 18:49:52 UTC
The upstream bug has been closed for lack of activity.

Maeredhel, Nils, we'd really need some further info from you before we can move forward.

One useful thing could be a stack trace - see https://chromium.googlesource.com/chromium/src/+/master/docs/linux_debugging.md for instructions.

Another useful one could be which system library is causing the problem. You could try modifying the ebuild to remove various use_system_foo switches (and allow using the bundled library in src_prepare), and see which one makes the issue go away.
Comment 5 Nils Holland 2015-09-21 07:17:28 UTC
Right - I do believe that this bug can be closed, as it seems to have been caused by a user error. :-/

At least in my case, I was able to eventually determine that I didn't have all the options enabled in my kernel that the chromium sandbox feature needs to run properly. Enabling these features and rebuilding my kernel, chromium would run just fine. I believe that initially, the chromium ebuilds didn't check for this and I only found my mistake by fiddling around a little. By now, chromium.eclass includes the function "chromium_suid_sandbox_check_kernel_config()" which alerts the user if his kernel is not properly configured to run chromium in its sandboxed environment.

So unless Maeredhel has something else to say, I'd say that this issue can be closed and am sorry to have bothered you folks with something that was clearly my own fault.