chromium/chrome in a vserver guest?

Hello

I'm successfully (and maybe even securely) using Xorg in a vserver
guest (I'll add more details to the wiki about X soon). The one
problem I haven't found a solution so far is running chromium.

$ chromium-browser
Failed to move to new PID namespace: Operation not permitted
^C

$ chromium-browser --no-sandbox
[12306:12306:699047412629:ERROR:renderer_main.cc(213)] Running without
renderer sandbox
# works but that's obviously suboptimal

Now I've read that chrome/chromium has been and still is using seccomp
for their sandbox on Linux [1][2], at least in some configuration or
part of its sandboxing; now for the part where it does indeed use
seccomp, to my understanding there would be no use for PID namespaces
(seccomp would inhibit access to syscalls concerning PIDs), so that
leaves me to suspect they either use namespaces in the part outside
the seccomp'ed thread, or that chromium from Debian stable and testing
are relying on something else than seccomp.

I can't verify whether seccomp is being used with strace on a
non-vserver machine, as that too makes it run into the "Failed to move
to new PID namespace: Operation not permitted" error.

Does anyone know more, or has found a solution to running chromium
with sandboxing?

Re: chromium/chrome in a vserver guest?

On Thu, Dec 01, 2011 at 02:32:48PM -0500, Christian Jaeger wrote:
> Hello

> I'm successfully (and maybe even securely) using Xorg in a
> vserver guest (I'll add more details to the wiki about X soon).

looking forward to the wiki improvements ...

> The one problem I haven't found a solution so far is running
> chromium.

> $ chromium-browser
> Failed to move to new PID namespace: Operation not permitted
> ^C

> $ chromium-browser --no-sandbox
> [12306:12306:699047412629:ERROR:renderer_main.cc(213)] Running
> without renderer sandbox
> # works but that's obviously suboptimal

> Now I've read that chrome/chromium has been and still is using
> seccomp for their sandbox on Linux [1][2], at least in some
> configuration or part of its sandboxing; now for the part where
> it does indeed use seccomp, to my understanding there would
> be no use for PID namespaces (seccomp would inhibit access
> to syscalls concerning PIDs), so that leaves me to suspect
> they either use namespaces in the part outside the seccomp'ed
> thread, or that chromium from Debian stable and testing
> are relying on something else than seccomp.

Re: chromium/chrome in a vserver guest?

2011/12/1 Herbert Poetzl <herbert <at> 13thfloor.at>:
> what kernel/patch versions are we talking about and

3.0.7-vs2.3.1

> why does it fail on the non-vserver machine?

It only fails on the non-vserver machine when running under strace:

$ strace -o _str -f chromium-browser
Failed to move to new PID namespace: Operation not permitted

$ strace -o _str -f chromium-browser --no-sandbox
# works except it says it's not using sandboxing

$ chromium-browser
# works normally

_str never contains any reference to SECCOMP, either because the
seccomp part would come up later than the pid namespacing, or because
it's not actually using seccomp anyway.

I've looked at the seccompsandbox project site[1], which indicates the
project is still actively developed, although it's not clear whether
it's being used in chromium or not; I'll try to find out more.

[1] http://code.google.com/p/seccompsandbox/

Christian.

vnamespace mount -o remount,ro does not make it read-only

Hello,

I want to bind mount a directory from the host (named 'tn') into a
running vserver (named 't3'). I want the bind mount to be read-only.
Yes I already know that mount --bind can't do them read-only
immediately, so there will be a period during which the guest can
write, but I can live with that right now. The real problem is that I
can't manage to make the bind mount read-only at all.

When I do the mounts from /etc/vservers/t3/fstab like with:
/root/GIT /root/GIT none noatime,ro,bind 0 0
they are correctly read-only. But when I try to do it manually, no go:

First, to show that the commands work in the host context:

tn:~# mount --bind ~chris/GIT/ /var/lib/vservers/t3/home/chris/GIT
tn:~# touch /var/lib/vservers/t3/home/chris/GIT/fe
tn:~# mount -o remount,ro /var/lib/vservers/t3/home/chris/GIT
tn:~# touch /var/lib/vservers/t3/home/chris/GIT/fe
touch: cannot touch `/var/lib/vservers/t3/home/chris/GIT/fe':
Read-only file system

i.e. as expected. Now,

tn:~# vnamespace -e t3 mount --bind ~chris/GIT/
/var/lib/vservers/t3/home/chris/GIT
tn:~# vnamespace -e t3 mount -o remount,ro /var/lib/vservers/t3/home/chris/GIT
tn:~# vnamespace -e t3 touch /var/lib/vservers/t3/home/chris/GIT/fe
touch: cannot touch `/var/lib/vservers/t3/home/chris/GIT/fe':
Read-only file system

Re: vnamespace mount -o remount,ro does not make it read-only

Just when I finished the above, I had an idea:

(Mis-using the existing dir /var/lib/vservers/build64/home/chris/GIT
just because I'm too lazy to create a directory somewhere else)

tn:/etc/vservers# vnamespace -e t3 mount --bind ~chris/GIT/
/var/lib/vservers/build64/home/chris/GIT
tn:/etc/vservers# vnamespace -e t3 mount -o remount,ro
/var/lib/vservers/build64/home/chris/GIT
tn:/etc/vservers# vnamespace -e t3 mount --bind
/var/lib/vservers/build64/home/chris/GIT
/var/lib/vservers/t3/home/chris/GIT
chris <at> t3:~$ touch GIT/feh
touch: cannot touch `GIT/feh': Read-only file system

*good* (this also avoids the time gap with read-write access from the guest)

But I'd still like to know why the remount,ro had no effect on the
guest in the first case.

Christian.

Re: vnamespace mount -o remount,ro does not make it read-only

On Thu, Dec 01, 2011 at 10:17:18PM -0500, Christian Jaeger wrote:
> Hello,

> I want to bind mount a directory from the host (named 'tn')
> into a running vserver (named 't3'). I want the bind mount to
> be read-only. Yes I already know that mount --bind can't do
> them read-only immediately, so there will be a period during
> which the guest can write, but I can live with that right now.

you can actually make it read only first and then move
it into the guest ... see below

> The real problem is that I can't manage to make the bind mount
> read-only at all.

> When I do the mounts from /etc/vservers/t3/fstab like with:
> /root/GIT /root/GIT none noatime,ro,bind 0 0
> they are correctly read-only. 

> But when I try to do it manually, no go:
> First, to show that the commands work in the host context:

> tn:~# mount --bind ~chris/GIT/ /var/lib/vservers/t3/home/chris/GIT
> tn:~# touch /var/lib/vservers/t3/home/chris/GIT/fe
> tn:~# mount -o remount,ro /var/lib/vservers/t3/home/chris/GIT
> tn:~# touch /var/lib/vservers/t3/home/chris/GIT/fe
> touch: cannot touch `/var/lib/vservers/t3/home/chris/GIT/fe':
> Read-only file system

> i.e. as expected. Now,

Re: vnamespace mount -o remount,ro does not make it read-only

Re: chromium/chrome in a vserver guest?

On Thu, Dec 01, 2011 at 04:33:40PM -0500, Christian Jaeger wrote:
> > what kernel/patch versions are we talking about and
> 3.0.7-vs2.3.1

3.1.0-vs2.3.1-rc2 here, 0.30.216-pre2967 tools.
chromium 15.0.874.106~r107270-1

However, I run this very kernel on my laptop and try and start chromium
in context 0 (host) as a normal user. It fails unless I specify
'--no-sandbox'
'fails' is: the browser comes up but can't load any webpages. It stopped
working a few weeks ago. I rarely use chromium, I think the timing fits
with me shifting from 2.6.38.6-vs2.3.0.37-rc15 to 3.0.4-vs2.3.1-pre10.1.

Regards,
	Adrian
--

-- 
LiHAS - Adrian Reyer - Hessenwiesenstraße 10 - D-70565 Stuttgart
Fon: +49 (7 11) 78 28 50 90 - Fax:  +49 (7 11) 78 28 50 91
Mail: lihas <at> lihas.de - Web: http://lihas.de
Linux, Netzwerke, Consulting & Support - USt-ID: DE 227 816 626 Stuttgart

xid=__ vshelper.init: can not determine xid of vserver

Hello, 

I try to start a Suse 11.1 that ist installed with rsync. 

root <at> squeeze64:/var/lib/vservers/suse111/etc/init.d# vserver suse111 start
vshelper.init: can not determine xid of vserver 'suse111'; returned value was ''

This usually means that you're using an init-less init-style, but the
guest isn't configured to start any service. Try enabling a service,
changing the init-style, or making the contexts persistent.

An error occured after executing the vserver startup sequence. This
means that some processes may exist in the created context and the
manual execution of
  /usr/sbin/vserver '/etc/vservers/suse111' stop
is recommended to fix this.

# vserver --debug suse111 start
[...]
++ /usr/sbin/vserver-info - FEATURE vshelper
++ test -n ''
++ return 0
++ local xid
+++ /usr/sbin/vserver-info /etc/vservers/suse111 CONTEXT false
++ xid=
++ warning 'vshelper.init: can not determine xid of vserver '\''suse111'\''; returned value was '\'''\''

This usually means that you'\''re using an init-less init-style, but the
[...]

root <at> squeeze64:/etc/vservers/suse111# cat context
1099

I installed suse111 using rsync an deleting some boot- and hardware-scripts in /etc/init.d/: 

# vserver suse111 build --context 1099 --hostname suse111 --interface \
 suse111=eth0:192.168.0.99/24  -m rsync -- --source /mnt/

root <at> squeeze64:~# ls /var/lib/vservers/suse111/ -l
insgesamt 96
drwxr-xr-x   2 root root  4096  5. Dez 19:38 bin
drwxr-xr-x   3 root root  4096  5. Dez 19:56 boot
drwxr-xr-x   2 root root  4096  6. Dez 13:19 dev
drwxr-xr-x 107 root root 12288  6. Dez 14:30 etc
drwxr-xr-x   3 root root  4096  5. Dez 20:00 home
drwxr-xr-x  16 root root 12288  5. Dez 19:44 lib
drwx------   2 root root  4096  5. Dez 19:25 lost+found
drwxr-xr-x   3 root root  4096  6. Dez 12:30 media
drwxr-xr-x   2 root root  4096  3. Dez 2008  mnt
drwxr-xr-x   3 root root  4096  9. Dez 2008  opt
dr-xr-xr-x   2 root root  4096  6. Dez 12:28 proc
drwx------   8 root root  4096  6. Dez 12:45 root
drwxr-xr-x   3 root root 12288  5. Dez 19:42 sbin
drwxr-xr-x   4 root root  4096  9. Dez 2008  srv
drwxr-xr-x   2 root root  4096  6. Dez 12:28 sys
drwxrwxrwt  12 root root  4096  6. Dez 12:47 tmp
drwxr-xr-x  12 root root  4096  9. Dez 2008  usr
drwxr-xr-x  15 root root  4096  9. Dez 2008  var

root <at> squeeze64:~# df
Dateisystem          1K‐Blöcke   Benutzt Verfügbar Ben% Eingehängt auf
[...]
/dev/mapper/vg--prax1-suse111
                      20642428   3624736  15969116  19% /var/lib/vservers/suse111
[...]

root <at> squeeze64:~# cat /etc/vservers/suse111/fstab
none    /proc           proc    defaults                0 0
#none   /tmp            tmpfs   size=16m,mode=1777      0 0
#none   /dev/pts        devpts  gid=5,mode=620          0 0

Any ideas? In http://linux-vserver.org/Installing_an_openSUSE_vserver_guest
there are some hints concerning SUSE, but it's a vserver problem here, isn't?
A Suse11.2 ist running on another machine without problems, I never patched 
vserver.start.

tia
Ekkard

Re: xid=__ vshelper.init: can not determine xid of vserver

http://www.mail-archive.com/vserver <at> list.linux-vserver.org/msg09562.html 

 "This means your guest isn't starting any process, and thus the context is gone before
 the start process is even finished. You could: - change the initstyle to plain 
 (echo plain > /usr/local/etc/vservers/S1.myvserver01/apps/init/style), - set the
 persistent flag (echo ^38 >> /usr/local/etc/vservers/S1.myvserver01/flags), ..."

It seems to be a fault in configuration of the guest. 

root <at> squeeze64:/etc/vservers/suse111# echo plain > style
root <at> squeeze64:~# vserver suse111 start
Mount failed for selinuxfs on /selinux:  No such file or directory
root <at> squeeze64:~# vserver-stat
CTX   PROC    VSZ    RSS  userTIME   sysTIME    UPTIME NAME
1099     1   0.9M   384K   0m00s43   0m00s17   0m09s48 suse111
root <at> squeeze64:~# vserver suse111 enter
vlogin: openpty(): No such file or directory
root <at> squeeze64:~# vserver suse111 stop
A timeout occured while waiting for the vserver to finish and it will
be killed by sending a SIGKILL signal. The following process list
might be useful for finding out the reason of this behavior:
----------------------------------------------------------------------
 5744  1099 suse111       ?        Ss     0:00 init [6]
 5744  1099 suse111       ?        Ss     0:00 init [6]
----------------------------------------------------------------------

init hangs now.
I patched vserver.start like explained in 
http://linux-vserver.org/Installing_an_openSUSE_vserver_guest
but it didn't help. I deleted /etc/vservers/suse111/style
and the vserver is able to be startet(!) without "style" file!
What a surprise! Now I have the same configuration as before 
with the xid error. A ghost working with vserver? 

Where does init hang? 

Ekkard