Why in the world is root running chromium

graysky · 2017-09-24 13:55:06

Recently, executing chromium on my workstation results in the browser not loading but two processes running, one of which is owned by root which seems very suspicious to me.

% ps aux | grep chrom 
facade  13485  0.1  0.1 481344 41960 pts/0    Sl+  09:51   0:00 /usr/lib/chromium/chromium --disable-reading-from-canvas=1
root     13487  0.0  0.0   6456   836 pts/0    D+   09:51   0:00 /usr/lib/chromium/chrome-sandbox /usr/lib/chromium/chromium --type=zygote

A reboot restores the normal behavior (ie, my user running chromium not root). Have others seen this?

Trilby · 2017-09-24 14:09:17

How do you start chromium? Do you use the package from the repos? Have you modified it in anyway?

Do you have system level (not --user) services running that interact with chromium in any way? (e.g., that PSD or ASD of yours).

Last edited by Trilby (2017-09-24 14:10:06)

seth · 2017-09-24 15:32:22

https://bugs.archlinux.org/task/36969

Uriel_Bernhard48 · 2017-09-24 21:23:53

chrome-sandbox is setuid wrapper for creating sandboxing. I think it should drop it's capabilities after it's set. Maybe you have something which blocks it.

How did you reproduce it? If it works ok after reboot, when it starting to behave strangely?

Last edited by Uriel_Bernhard48 (2017-09-24 21:26:32)

graysky · 2018-05-21 20:49:12

Happened again just now... (not a necrobump since there is no real dated info here):

% ps aux | grep chrom
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root      9990  0.1  0.0   6484   812 ?        D    16:43   0:00 /usr/lib/chromium/chrome-sandbox /usr/lib/chromium/chromium --type=zygote
root      9999  0.5  0.0   6484   832 ?        D    16:43   0:00 /usr/lib/chromium/chrome-sandbox /usr/lib/chromium/chromium --type=zygote

No idea why or how. If I forcible kill those processes, then try running `chromium` again, the same thing happens:

1) No chromium GUI.
2) 2 new processes owned by root are executed.

WTF?

seth · 2018-05-22 06:12:35

Some race condition? There should be one such process and it should drop its privileges asap.
You could try to gdb or strace into those processes and look what they're doing (they certainly wait for some ioctl to return, see the STAT col)

Also see https://bbs.archlinux.org/viewtopic.php … 7#p1737957

pr0dukter · 2018-05-28 21:02:55

read up on com.google.keystone() and be horrified, then try to read enough sources saying its basically benigh while not giving in to wha you know to be true about this survei - er metadata - er keyscore er uh keystone function thats in every google product, the qt webkits etc. this is also why chromium uses so much ram and your disks keep spinning seemingly without end after closing any chromium process.

graysky · 2018-05-28 21:12:36

pr0dukter wrote:

read up on com.google.keystone() and be horrified, then try to read enough sources saying its basically benigh while not giving in to wha you know to be true about this survei - er metadata - er keyscore er uh keystone function thats in every google product, the qt webkits etc. this is also why chromium uses so much ram and your disks keep spinning seemingly without end after closing any chromium process.

Ummm... what?

circleface · 2018-05-29 00:24:20

Pr0dukter, please read https://wiki.archlinux.org/index.php/Co … d_projects . Please respect other products and companies, even if you do not agree with them. There is no need to hijack this thread with a rant about Chromium.

pr0dukter · 2018-05-29 04:53:29

uh its the reason chromium runs as root and uses so much memory

seth · 2018-05-29 06:30:56

The reason the chromium sandbox ran (and for a custom kernel maybe "runs") as root is because of https://bugs.archlinux.org/task/36969
It uses "so much memory" because
a) it's a browser and the web got bloated somewhen in the past 15 years
b) it runs masses of processes w/o SHM for sandboxing security
If you want to prevent it from spinning your disk: use the private browsing mode or delete your user data using either chromium settings or just nuke your ~/.config/chromium

Keystone is googles update service and whatever malicious stuff it might or not do:

grep -ri keystone /usr/lib/chromium

(zgrep does neither, the IP doesn't show in the logs) - afaik it's an OSX only thing anyway and chromium isn't chrome.
If by "keystone" you refer to anything else: chromium is open source, so maybe point the worrysome code? Or some discussion or bug report about this?

Google btw. gathers data about you whenever you use the internet, almost every major webpage loads stuff from them (scripts, fonts, ads, ...) - regardless of which browser you use.
And of course if you search using google, they pretty much know who and what you are.

loqs · 2018-05-29 13:29:15

@seth I thought usermode namespace required sysctl kernel.unprivileged_userns_clone=1 on the arch kernels.
@graysky if you run `chromium --disable-setuid-sandbox` does chromium start or do you get a FATAL error?

seth · 2018-05-29 13:53:14

Yes does (which is probably why it's still suid' and drops privs by default)
graysky's problem looks much like a race condition to me - there should not be two sandbox processes, so some stale PID lock in /tmp/.org.chromium.Chromium.* might mess up things (though I've got 4 of them and no coredump for chromium, nor this particular issue)
There're two similar processed both waiting for ioctl responses (what probably prevents them from dropping privs since they never get there) - I'd still suggest to strace or gdb attach them since it will most likely (hopefully) reveal what they're waiting for.

graysky · 2018-05-29 19:13:41

@loqs - Fails to start:

% chromium --disable-setuid-sandbox
[22638:22638:0529/151308.772534:FATAL:zygote_host_impl_linux.cc(124)] No usable sandbox! Update your kernel or see https://chromium.googlesource.com/chromium/src/+/master/docs/linux_suid_sandbox_development.md for more information on developing with the SUID sandbox. If you want to live dangerously and need an immediate workaround, you can try using --no-sandbox.
[1]    22638 abort (core dumped)  chromium --disable-setuid-sandbox

progandy · 2018-05-29 19:21:56

@gravsky: Chromium needs either SUID or user namespaces to sandbox itself like loqs said. It works if you allow them or if you disable the sandbox completely.

sudo sysctl kernel.unprivileged_userns_clone=1
chromium --disable-setuid-sandbox

chromium --no-sandbox

Last edited by progandy (2018-05-29 19:24:51)

Arch Linux

#1 2017-09-24 13:55:06

Why in the world is root running chromium

#2 2017-09-24 14:09:17

Re: Why in the world is root running chromium

#3 2017-09-24 15:32:22

Re: Why in the world is root running chromium

#4 2017-09-24 21:23:53

Re: Why in the world is root running chromium

#5 2018-05-21 20:49:12

Re: Why in the world is root running chromium

#6 2018-05-22 06:12:35

Re: Why in the world is root running chromium

#7 2018-05-28 21:02:55

Re: Why in the world is root running chromium

#8 2018-05-28 21:12:36

Re: Why in the world is root running chromium

#9 2018-05-29 00:24:20

Re: Why in the world is root running chromium

#10 2018-05-29 04:53:29

Re: Why in the world is root running chromium

#11 2018-05-29 06:30:56

Re: Why in the world is root running chromium

#12 2018-05-29 13:29:15

Re: Why in the world is root running chromium

#13 2018-05-29 13:53:14

Re: Why in the world is root running chromium

#14 2018-05-29 19:13:41

Re: Why in the world is root running chromium

#15 2018-05-29 19:21:56

Re: Why in the world is root running chromium

Board footer