From: Bengt Richter <bokr@bokr.com>
To: Leo Prikler <leo.prikler@student.tugraz.at>
Cc: 47106@debbugs.gnu.org
Subject: bug#47106: Bubblewrap hates Guix containers 😞
Date: Tue, 16 Mar 2021 11:54:42 +0100 [thread overview]
Message-ID: <20210316105442.GA3903@LionPure> (raw)
In-Reply-To: <d0638eba7e63c71edd4267c1675e0ea7f5b7b4ae.camel@student.tugraz.at>
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
finally, it is interesting to see
lsof -U|less
but on my laptop I just got
lsof -U|wc
403 3760 34643
so its a lot to look at.
Hopefully less in a container ;)
--
Regards,
Bengt Richter
next prev parent reply other threads:[~2021-03-16 10:56 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-12 17:43 bug#47106: Bubblewrap hates Guix containers 😞 Leo Prikler
2021-03-13 10:48 ` Ludovic Courtès
2021-03-13 11:07 ` Leo Prikler
2021-03-13 12:27 ` Bengt Richter
2021-03-13 14:43 ` Leo Prikler
2021-03-13 17:07 ` Bengt Richter
2021-03-13 18:01 ` Leo Prikler
2021-03-14 17:45 ` Bengt Richter
2021-03-14 18:05 ` Leo Prikler
2021-03-14 20:32 ` Ludovic Courtès
2021-03-14 20:43 ` Leo Prikler
2021-03-15 9:52 ` Ludovic Courtès
2021-03-15 10:14 ` Leo Prikler
2021-03-15 13:29 ` Ludovic Courtès
2021-03-16 10:54 ` Bengt Richter [this message]
2021-03-16 11:13 ` Leo Prikler
2021-04-14 20:07 ` Leo Famulari
2021-04-14 21:23 ` Leo Prikler
2021-04-14 22:00 ` Leo Famulari
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210316105442.GA3903@LionPure \
--to=bokr@bokr.com \
--cc=47106@debbugs.gnu.org \
--cc=leo.prikler@student.tugraz.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).