[GH-ISSUE #934] evince starts service outside of sandbox

gitea-mirror commented

2026-05-05 06:19:14 -06:00

Owner

Originally created by @valoq on GitHub (Nov 22, 2016).
Original GitHub issue: https://github.com/netblue30/firejail/issues/934

when running "firejail evince" the pplication starts like expected as a child process of firejail. However as soon as a pdf document is opened /usr/lib/evince/evinced is started by systemd. Assuming that evinced is actually parsing the pdf file, this behavior defeats the jailing purpose since evinced is not jailed.

When running two different instances of "firejail evince" opening different pdf files, only the first process trigers the start of evinced by systemd. Therefore once evinced is started other evince processes use it. This can be used the other issue with agent services keeping firejail from closing the following improvement could solve these issues:

have an option in firejail to start additional services either outside or inside the sandbox.
That way evince could specify in the profile to start evinced before opening any files and other profiles could specify to start agent services outside of the sandbox or inside another sandbox.

Originally created by @valoq on GitHub (Nov 22, 2016). Original GitHub issue: https://github.com/netblue30/firejail/issues/934 when running "firejail evince" the pplication starts like expected as a child process of firejail. However as soon as a pdf document is opened /usr/lib/evince/evinced is started by systemd. Assuming that evinced is actually parsing the pdf file, this behavior defeats the jailing purpose since evinced is not jailed. When running two different instances of "firejail evince" opening different pdf files, only the first process trigers the start of evinced by systemd. Therefore once evinced is started other evince processes use it. This can be used the other issue with agent services keeping firejail from closing the following improvement could solve these issues: have an option in firejail to start additional services either outside or inside the sandbox. That way evince could specify in the profile to start evinced before opening any files and other profiles could specify to start agent services outside of the sandbox or inside another sandbox.

gitea-mirror

2026-05-05 06:19:14 -06:00

closed this issue
added the
information_old
label

gitea-mirror commented

2026-05-05 06:19:20 -06:00

Author

Owner

@netblue30 commented on GitHub (Nov 22, 2016):

How do they communicate with systemd?

@netblue30 commented on GitHub (Nov 22, 2016): How do they communicate with systemd?

gitea-mirror commented

2026-05-05 06:19:24 -06:00

Author

Owner

@valoq commented on GitHub (Nov 23, 2016):

I don't know. Any idea about how to find that out?

@valoq commented on GitHub (Nov 23, 2016): I don't know. Any idea about how to find that out?

gitea-mirror commented

2026-05-05 06:19:26 -06:00

Author

Owner

@curiosity-seeker commented on GitHub (Nov 23, 2016):

Assuming that evinced is actually parsing the pdf file ...

I don't use Evince since I'm running KDE. But according to the Evince FAQ Poppler is used for rendering PDF files. What do you get when you open several PDF files and execute firejail --list or firejail --tree ?

@curiosity-seeker commented on GitHub (Nov 23, 2016): > Assuming that evinced is actually parsing the pdf file ... I don't use Evince since I'm running KDE. But according to the [Evince FAQ](https://wiki.gnome.org/Apps/Evince/FrequentlyAskedQuestions) Poppler is used for rendering PDF files. What do you get when you open several PDF files and execute firejail --list or firejail --tree ?

gitea-mirror commented

2026-05-05 06:19:30 -06:00

Author

Owner

@valoq commented on GitHub (Nov 24, 2016):

Okular uses poppler too, as well as most other pdf viewers on linux. However only with evince I get an additional process started by systemd. Note that poppler is a library not a service so this is a specific behaviour of evince.

when I run two instances of "firejail evince" and open tree different documents only the first one will trigger the evinced process: /usr/lib/evince/evinced

Result of firejail --tree:

4864:valoq:firejail evince
4865:valoq:firejail evince
4872:valoq:evince
4885:valoq:/usr/bin/evince /home/valoq/test.pdf
4921:valoq:firejail evince
4922:valoq:firejail evince
4929:valoq:evince

The first instance opened two documents, but only the second is listed as seen above. The second instance has opened one file but did not start another evinced process

/usr/lib/evince/evinced has the following parent process:
/usr/lib/systemd/systemd --user

I have seen this behaviour with other gnome applications. The gnome project uses systemd services a lot and this will be a problem when used with firejail and affect likely more programs then just evince

@valoq commented on GitHub (Nov 24, 2016): Okular uses poppler too, as well as most other pdf viewers on linux. However only with evince I get an additional process started by systemd. Note that poppler is a library not a service so this is a specific behaviour of evince. when I run two instances of "firejail evince" and open tree different documents only the first one will trigger the evinced process: /usr/lib/evince/evinced Result of firejail --tree: 4864:valoq:firejail evince 4865:valoq:firejail evince 4872:valoq:evince 4885:valoq:/usr/bin/evince /home/valoq/test.pdf 4921:valoq:firejail evince 4922:valoq:firejail evince 4929:valoq:evince The first instance opened two documents, but only the second is listed as seen above. The second instance has opened one file but did not start another evinced process /usr/lib/evince/evinced has the following parent process: /usr/lib/systemd/systemd --user I have seen this behaviour with other gnome applications. The gnome project uses systemd services a lot and this will be a problem when used with firejail and affect likely more programs then just evince

gitea-mirror commented

2026-05-05 06:19:33 -06:00

Author

Owner

@netblue30 commented on GitHub (Nov 27, 2016):

Maybe you can run the service under firejail. Look for the service/unit file and add firejail to ExecStart. I didn't try it myself, but it should work.

@netblue30 commented on GitHub (Nov 27, 2016): Maybe you can run the service under firejail. Look for the service/unit file and add firejail to ExecStart. I didn't try it myself, but it should work.

gitea-mirror commented

2026-05-05 06:19:35 -06:00

Author

Owner

@valoq commented on GitHub (Dec 4, 2016):

Maybe you can run the service under firejail. Look for the service/unit file and add firejail to ExecStart. I didn't try it myself, but it should work.

Changing the ExecStart command line to firejail --profile=/etc/firejail/evince.profile /usr/lib/evince/evinced did not work as expected.
Running firejail evince on the console I got:

Failed to get an inhibit portal proxy: The name org.freedesktop.portal.Desktop
Error registering document: GDBus.Error:org.freedesktop.DBus.Error.InvalidArgs: Unit evince.service is not loaded properly: Invalid argument.

However evince started, displayed the document correctly and there was no evinced to be found

Another experiment with --ipc-namespace was even more confusing:

running firejail --noprofile --ipc-namespace xterm

inside I run:
evince test.pdf

result:
Trace/breakpoint trap (core dumped)

Then I run:
/usr/lib/evince/evinced &

and then:
evince test.pdf

both evince and evinced are inside the jail.
However, closing the document and opening another will shutdown evinced and restart evinced outside of the jail even though it did not work before.

Evinced is apparently started by dbus (via systemd?) using /usr/lib/systemd/user/evince.service

[Unit]
Description=Evince document viewer
Documentation=man:evince(1)

[Service]
Type=dbus
BusName=org.gnome.evince.Daemon
ExecStart=/usr/lib/evince/evinced

IPC Namespaces isolates System V IPC and POSIX message queues.
I don't know how the communication with systemd and dbus works but it seems to not affect them.

Given that this issue seems to affect more applications then just evince, it creates quite a problem.

@valoq commented on GitHub (Dec 4, 2016): > Maybe you can run the service under firejail. Look for the service/unit file and add firejail to ExecStart. I didn't try it myself, but it should work. Changing the ExecStart command line to firejail --profile=/etc/firejail/evince.profile /usr/lib/evince/evinced did not work as expected. Running firejail evince on the console I got: Failed to get an inhibit portal proxy: The name org.freedesktop.portal.Desktop Error registering document: GDBus.Error:org.freedesktop.DBus.Error.InvalidArgs: Unit evince.service is not loaded properly: Invalid argument. However evince started, displayed the document correctly and there was no evinced to be found Another experiment with --ipc-namespace was even more confusing: running firejail --noprofile --ipc-namespace xterm inside I run: evince test.pdf result: Trace/breakpoint trap (core dumped) Then I run: /usr/lib/evince/evinced & and then: evince test.pdf both evince and evinced are inside the jail. However, closing the document and opening another will shutdown evinced and restart evinced outside of the jail even though it did not work before. Evinced is apparently started by dbus (via systemd?) using /usr/lib/systemd/user/evince.service [Unit] Description=Evince document viewer Documentation=man:evince(1) [Service] Type=dbus BusName=org.gnome.evince.Daemon ExecStart=/usr/lib/evince/evinced IPC Namespaces isolates System V IPC and POSIX message queues. I don't know how the communication with systemd and dbus works but it seems to not affect them. Given that this issue seems to affect more applications then just evince, it creates quite a problem.

gitea-mirror commented

2026-05-05 06:19:37 -06:00

Author

Owner

@valoq commented on GitHub (Dec 4, 2016):

Addition:


running firejail --noprofile --ipc-namespace xterm

inside I run:
evince test.pdf

result:
Trace/breakpoint trap (core dumped)

If evince is run a second time, it works just like when the unit failed to start after I changed the ExecStart command.

As a result:
running: "firejail --ipc-namespace evince; evince" works as well with the first instance failing to start.
However evinced is started outside the jail again when a document is opened.

adding "blacklist /usr/lib/systemd" and "blacklist /usr/lib/evince/evinced" to the evince profile did not work for some reason as well. This is unexpected. Does blacklist not work in the /usr path?

@valoq commented on GitHub (Dec 4, 2016): Addition: ``` running firejail --noprofile --ipc-namespace xterm inside I run: evince test.pdf result: Trace/breakpoint trap (core dumped) ``` If evince is run a second time, it works just like when the unit failed to start after I changed the ExecStart command. As a result: running: "firejail --ipc-namespace evince; evince" works as well with the first instance failing to start. However evinced is started outside the jail again when a document is opened. adding "blacklist /usr/lib/systemd" and "blacklist /usr/lib/evince/evinced" to the evince profile did not work for some reason as well. This is unexpected. Does blacklist not work in the /usr path?

gitea-mirror commented

2026-05-05 06:19:40 -06:00

Author

Owner

@netblue30 commented on GitHub (Dec 5, 2016):

Yes, blacklists should work find under /usr.

We'll have to keep an eye on it, it is not clear why these people chose to run evince like a server started by systemd. In the older versions (I am on Debian stable) evince runs as a single program. This idea of starting servers for trivial reasons is a very bad idea, and it could became a huge security problem. They do the same for gnome-terminal. I guess I'll be moving to mupdf,

@netblue30 commented on GitHub (Dec 5, 2016): Yes, blacklists should work find under /usr. We'll have to keep an eye on it, it is not clear why these people chose to run evince like a server started by systemd. In the older versions (I am on Debian stable) evince runs as a single program. This idea of starting servers for trivial reasons is a very bad idea, and it could became a huge security problem. They do the same for gnome-terminal. I guess I'll be moving to mupdf,

gitea-mirror commented

2026-05-05 06:19:41 -06:00

Author

Owner

@valoq commented on GitHub (Dec 5, 2016):

The blacklist does work, however the blacklisted files are used outside the sandbox.

@valoq commented on GitHub (Dec 5, 2016): The blacklist does work, however the blacklisted files are used outside the sandbox.

gitea-mirror commented

2026-05-05 06:19:45 -06:00

Author

Owner

@valoq commented on GitHub (Dec 6, 2016):

Here is what strace showed:

connect(3, {sa_family=AF_UNIX, sun_path="/run/user/1000/wayland-0"}, 27) = -1 ENOENT (No such file or directory)
connect(5, {sa_family=AF_UNIX, sun_path="/run/user/1000/bus"}, 20) = 0
connect(6, {sa_family=AF_UNIX, sun_path="/run/user/1000/bus"}, 110) = 0

@valoq commented on GitHub (Dec 6, 2016): Here is what strace showed: connect(3, {sa_family=AF_UNIX, sun_path="/run/user/1000/wayland-0"}, 27) = -1 ENOENT (No such file or directory) connect(5, {sa_family=AF_UNIX, sun_path="/run/user/1000/bus"}, 20) = 0 connect(6, {sa_family=AF_UNIX, sun_path="/run/user/1000/bus"}, 110) = 0

gitea-mirror referenced this issue

2026-05-05 10:06:11 -06:00

[PR #634] [MERGED] Pidgin private-bin conversion #3693

Rows
Columns

[GH-ISSUE #934] evince starts service outside of sandbox #634