Subject: bug#47106: Bubblewrap hates Guix containers 😞

From: Leo Prikler <[email-masked]>
Date: Tue, 16 Mar 2021 12:13:10 +0100

Hi,
Am Dienstag, den 16.03.2021, 11:54 +0100 schrieb Bengt Richter:
> Hi Leo,
> One more favor? ;)
> 
> On +2021-03-14 19:05:24 +0100, Leo Prikler wrote:
> > Hi again³
> > 
> > Am Sonntag, den 14.03.2021, 18:45 +0100 schrieb Bengt Richter:
> > > Hi again^2,
> > > 
> > > Maybe
> > >     pstree -at
> > > would show a little more?
> > sh
> >   |-dbus-daemon --syslog-only --fork --print-pid 5 --print-address
> > 7
> > --sess
> >   |-dbus-launch --autolaunch=fa7a4d52637958ddd37547bb5d8bd9d2
> > --binary-
> > synt
> >   `-screen
> >       `-screen
> >           |-sh
> >           |   `-.epiphany-real
> >           |       |-WebKitNetworkPr 3 21
> >           |       |   |-{BMScavenger}
> >           |       |   |-{ReceiveQueue}
> >           |       |   |-{StorageTask}
> >           |       |   |-{Storage}
> >           |       |   |-{WebStorage}
> >           |       |   |-{background}
> >           |       |   |-{dconf worker}
> >           |       |   |-{erialBackground}
> >           |       |   |-{gdbus}
> >           |       |   `-{gmain}
> >           |       |-bwrap --args 37 --
> > /gnu/store/hqhxgw0i8xh38h6kwmyrkywcd24q5f1z-webk
> >           |       |   `-bwrap --args 37 --
> > /gnu/store/hqhxgw0i8xh38h6kwmyrkywcd24q5f1z-webk
> >           |       |       `-WebKitWebProces 1277 28
> >           |       |-{.epiphany-real}
> >           |       |-{BMScavenger}
> >           |       |-{HashSaltStorage}
> >           |       |-{IconDatabase}
> >           |       |-{PressureMonitor}
> >           |       |-2*[{ReceiveQueue}]
> >           |       |-{dconf worker}
> >           |       |-{e Compile Queue}
> >           |       |-{ebsiteDataStore}
> >           |       |-{gdbus}
> >           |       |-{gmain}
> >           |       |-{re Remove Queue}
> >           |       `-{tore Read Queue}
> >           `-sh
> >               `-pstree -at
> > > Also,
> > >     ls -lr /sys/class/drm
> > total 0
> > -r--r--r-- 1 65534 overflow 4096 Mar 14 17:59 version
> > lrwxrwxrwx 1 65534 overflow    0 Mar 14 17:58 ttm ->
> > ../../devices/virtual/drm/ttm
> > lrwxrwxrwx 1 65534 overflow    0 Mar 14 17:59 renderD128 ->
> > ../../devices/pci0000:00/0000:00:02.0/0000:01:00.0/drm/renderD128
> > lrwxrwxrwx 1 65534 overflow    0 Mar 14 17:59 card0-VGA-1 ->
> > ../../devices/pci0000:00/0000:00:02.0/0000:01:00.0/drm/card0/card0-
> > VGA-
> > 1
> > lrwxrwxrwx 1 65534 overflow    0 Mar 14 17:59 card0-HDMI-A-1 ->
> > ../../devices/pci0000:00/0000:00:02.0/0000:01:00.0/drm/card0/card0-
> > HDMI-A-1
> > lrwxrwxrwx 1 65534 overflow    0 Mar 14 17:58 card0-DVI-D-1 ->
> > ../../devices/pci0000:00/0000:00:02.0/0000:01:00.0/drm/card0/card0-
> > DVI-
> > D-1
> > lrwxrwxrwx 1 65534 overflow    0 Mar 14 17:58 card0 ->
> > ../../devices/pci0000:00/0000:00:02.0/0000:01:00.0/drm/card0
> > > if that's accessible -- I'm wondering if the version of screen
> > > in the container is built with libdrm and is bypassing X or ??
> > I doubt it is being built differently than screen normally is.
> > 
> > > Do you have a makefile or a guix something.scm defining
> > > what's built/packed into your container? 
> > Nah, it's a rather ad-hoc definition grown from what should be an
> > Eolie
> > container from the cookbook (also refer to #47097).
> > 
> >     guix environment --preserve='^DISPLAY$' --preserve=XAUTHORITY \
> >      --preserve=TERM \
> >      --expose=$XAUTHORITY \
> >      --expose=/etc/machine-id \
> >      --expose=/etc/ssl/certs/ \
> >      --expose=/sys/block --expose=/sys/class --expose=/sys/bus \
> >      --expose=/sys/dev --expose=/sys/devices \
> >      --ad-hoc epiphany nss-certs dbus procps coreutils psmisc
> > screen
> > 
> > Given that I expose most of /sys explicitly, you should take the
> > above
> > with a grain of salt.
> > 
> > > Sorry if my curiosity is making work for you, but I'd like to
> > > try containers down the road -- tho right now I'm taking a break
> > > from events IRL, so I may disappear for a while...
> > I'm not personally impacted by this bug or anything, it's much
> > rather a
> > follow-up to my attempted fix of #47097.  I think there might be
> > some
> > flaw in trying to run a sandbox inside a sandbox (like bubblewrap
> > inside `guix container`), that doesn't actually improve security in
> > any
> > meaningful way.
> > 
> > Regards,
> > Leo
> > 
> 
> If you can run this inside your container, I think it will be
> interesting:
>     lsof -U|grep -i wayland
> 
> The above ought to show quickly if wayland is running.
> 
> lsof -U shows the open sockets.
> 
> If the above shows nothing, try
>     lsof -U|grep -i x11
> or    
>     lsof -U|grep X
Nothing showed up for either, but this got me thinking.  Exposing
/tmp/.X11-unix/X1 did do away with the warning, now it's unexposed
dbus, missing icons, etc. etc.  Exposing all of /tmp instead yields 

** (epiphany:2): ERROR **: 11:11:28.855: Failed to start embed shell D-
Bus server on unix:dir=(null): Error binding to address: No such file
or directory

I still think that exposing all of that is perhaps not the wisest idea,
but eh…

Regards,
Leo