Re: [evince] evinced daemon

["jose aliste gmail com" <jose aliste gmail com>]

Hi, 

On Tue, Dec 6, 2016 at 3:13 PM, sivmu <sivmu web de> wrote:

Am 06.12.2016 um 18:54 schrieb jose aliste gmail com:
>>
>> Although this is not an issue for evince on its own, I would like to
>> know why evince behaves like this.
>> From experiments I found out that if I remove the evince.service file or
>> block access to the dbus socket, evince still seems to works as expected
>> without evinced. Another way to prevent this seems to be to use the
>> --disable-dbus flag.
>>
>
> The difference and the reason why evinced exists is because Evince is using
> different processes for different Documents. That is, if you have
> four documents opened in evince, then you'd have four evince processes +
> the evinced process. The Evinced process is there to coordinate between the
> different evince processes. Of course this is not necessary, it was a
> decision taken a long time ago, but last time we discussed this feature we
> were happy about it. That being said, there is always the question of add
> sandboxing to evince since we are dealing with pdf and there are a lot of
> security bugs involving pdf files. So any help in this direction would be
> welcomed.
>
> Greetings,
>
> José
>

Thanks for explaining.
What exact funcionality is missing when used without evinced?

It depends of what you call a feature. If you assume that pdf can contain malware, then you could potentially open a malware pdf file

taht makes evince crash. Assuming that, a feature is "if evince crashes, I don't want it to crash on all documents but only on one". That's the feature you would be missing. I don't recall if there are other reasons for it. 

The feedback I got from several more experienced linux devs, was that
the decision to use a daemon process here is questional to beginn with
from a security standpoint.

This statement is just an opinion, unless you backed up with more serious technical reasons. For instance, if evince uses one process for document, then you can sandbox evince to have access only to the file you have opened, instead of having access to all the filesystem. (I am not a security expert...) There is ongoing discussion in how to sandbox apps. Flatpak people are working precisely on adding the required functionality to sandbox gtk apps and other kinds of apps.

>From what I have seen, there are a growing number of applications that
use such a functionality on gnome and kde/plasma. Starting services via
dbus seems to be modern.

If you are interested in sandboxing evince in the future, then it might
be worth considering to avoid the use of such an daemon process. At
least in firejail it is a pain to deal with that.

I am (can't speak for others) waiting for flatpak to mature in order to look in how to sandbox evince. At that point, maybe we can avoid evinced, since it's just an implementation detail to have several processes, one process per pdf file.  Eliminating evinced, just for the sake of it, it's not something we will likely do in the near future. Of course, patches for sandboxing evince are welcome. 

Greetings

José