Re: [evince] evinced daemon

[sivmu <sivmu web de>]

Am 06.12.2016 um 19:27 schrieb 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.

If I understan you correctly, evinced is responsible for managing
coordiantion between several evince provesses.
The actual parsing is done by the specific evince processes and not by
evinced, is that correct?

Attachment: signature.asc
Description: OpenPGP digital signature