Open Bug 1745106 Opened 2 years ago Updated 2 years ago

Launching Firefox in a docker container that shares dbus with the host will hand off to Firefox in the host

Categories

(Firefox :: Security, defect)

defect

Tracking

()

UNCONFIRMED

People

(Reporter: m.akos.kms, Unassigned)

Details

Attachments

(2 files)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:94.0) Gecko/20100101 Firefox/94.0

Steps to reproduce:

I created a basic container that's running firefox inside an archlinux:latest image.
Here's the Dockerfile:
FROM archlinux:latest
RUN pacman -Syu && pacman-db-upgrade && pacman -S firefox --noconfirm
RUN groupadd firefox && useradd -g firefox --create-home --home-dir /home/firefox firefox
COPY start.sh /opt/
RUN chmod +x /opt/start.sh
To launch Firefox I used this hackjob of a command:
docker run -it
-v /tmp/.X11-unix:/tmp/.X11-unix
--device /dev/snd
-v firefoxSettings:/home/firefox
-v /dev/shm:/dev/shm:z
-v /etc/localtime:/etc/localtime:ro
-v /var/run/dbus:/var/run/dbus
-v /var/run/user/$(id -u)/bus:/var/run/user/1000/bus
-e DBUS_SESSION_BUS_ADDRESS="unix:path=/var/run/user/1000/bus"
-v /var/run/user/$(id -u)/pulse:/var/run/user/1000/pulse
-e PULSE_SERVER="unix:/run/user/1000/pulse/native"
-e DISPLAY=:0
--device=/dev/video0:/dev/video0
--rm
--group-add $(getent group audio | cut -d: -f3)
akos/firefox-docker su firefox -c /usr/bin/firefox
Host: Arch Linux, Docker version 20.10.11, build dea9396e18.

Actual results:

Firefox launched from Docker (if Firefox is running on my host too) will use my profile, act like it was launched outside of the container while it's running from the container.

Expected results:

Firefox launches with it's own separate profile inside the container even if Firefox is already running on the host.

Attached file Dockerfile

Dockerfile used

Attached file firefox-docker.sh

Script used to launch the container with firefox

The Bugbug bot thinks this bug should belong to the 'Toolkit::Startup and Profile System' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Startup and Profile System
Product: Firefox → Toolkit
Component: Startup and Profile System → Security
Product: Toolkit → Firefox
Attachment #9254451 - Attachment mime type: application/x-shellscript → text/plain

What I think is happening here is that because Firefox uses dbus to co-ordinate passing command line arguments to existing instances and it looks to me like you're sharing your host's dbus session with the docker container when Firefox is starting in the container it sees the firefox instance in the host and passes off to it.

Ignoring docker this is intentional. I don't know enough about dbus and our support for this scenario to know whether this is something we should or even can fix though. Glandium may have a better understanding that me.

Flags: needinfo?(mh+mozilla)
Severity: -- → S3

You can probably work around this by adding --no-remote or --new-instance to the command line arguments to Firefox.

Summary: Firefox in a Docker container loads my host's profile → Launching Firefox in a docker container that shares dbus with the host will hand off to Firefox in the host

I can add the following information: Thunderbird with the same dbus sharing setup does open a separate instance even if I have another copy running on the host directly, same goes for Chromium and other Electron based applications. Later today I could test Debian/Ubuntu or another distro as the base image instead of Arch.(In reply to Dave Townsend [:mossop] from comment #4)

What I think is happening here is that because Firefox uses dbus to co-ordinate passing command line arguments to existing instances and it looks to me like you're sharing your host's dbus session with the docker container when Firefox is starting in the container it sees the firefox instance in the host and passes off to it.

Ignoring docker this is intentional. I don't know enough about dbus and our support for this scenario to know whether this is something we should or even can fix though. Glandium may have a better understanding that me.

It's end of day for me, so redirecting to someone who's starting theirs and who probably knows even better than I would.

Flags: needinfo?(mh+mozilla) → needinfo?(stransky)

(In reply to Dave Townsend [:mossop] from comment #5)

You can probably work around this by adding --no-remote or --new-instance to the command line arguments to Firefox.

Both --no-remote and --new-instance arguments will launch Firefox in a separate process, running from the container itself, as expected.

QA Whiteboard: qa-not-actionable

(In reply to Ákos Miklós from comment #6)

I can add the following information: Thunderbird with the same dbus sharing setup does open a separate instance even if I have another copy running on the host directly, same goes for Chromium and other Electron based applications. Later today I could test Debian/Ubuntu or another distro as the base image instead of Arch.

It's because Thunderbird does not use DBus but XRemote.

Ignoring docker this is intentional. I don't know enough about dbus and our support for this scenario to know whether this is something we should or even can fix though. Glandium may have a better understanding that me.

It's because you share DBus connection with the container. When the DBus inside container is isolated from DBus host it won't happen.

Flags: needinfo?(stransky)

I think you need to set different DBUS_SESSION_BUS_ADDRESS but I know nothing about docker.

QA Whiteboard: qa-not-actionable → qa-not-actionable , qa-not-reproducible
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: