.desktop files in /usr/local of normal AppVM?

[Jean-Philippe Ouellet]

Hello,

On occasion I have wanted a single application installed in a normal
(non-template non-standalone) AppVM, with a desktop file persisting in
/usr/local/share/applications.

qvm-sync-appmenus on such a normal VM fails with:
ERROR: To sync appmenus for template based VM, do it on template instead

This makes sense for things in /usr/share/applications, as they will
not persist across reboots and broken .desktop files in dom0 are not
desired. However, it appears to me that persisting .desktop files in
/usr/local in a normal template-based AppVM is a legitimate use case.

I propose syncing actually be allowed on such VMs, but only result in
the union of its template's .desktop files and the .desktop files
under /usr/local.

Thoughts?

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I was thinking about something exactly like this too. For example I have
spotify installed in /usr/local in one of my AppVMs and would really
like to have .desktop file for it created automatically (currently I use
qvm-run manually, even though I could create .desktop manually).

I think the way to go is:

1. Have apps.templates and apps.tempicons (icon templates) directories
in every VM (/var/lib/qubes/*/*), not only templates. For templates sync
them from /usr/share/applications, for non-templates sync them from
/usr/local/share/applications.

2. While creating (or listing for Qubes Manager) .desktop files, first
look into AppVMs own apps.templates, then fallback to the one from VM
template. Same for apps.tempicons.

3. In any case, create .desktop files in apps directory of the VM
itself.

Unanswered question: how to deal with /usr/local/share/applications in
the template itself? According to the above algorithm, it will be
ignored. I don't see any use case for template-only application
(installed into /usr/local there). But surely somebody will trip over it,
sooner or later.

Am I missing anything else?

BTW Here is the code for Qubes 4.0:
https://github.com/marmarek/qubes-core-admin-linux/blob/core3-devel/qubesappmenus/__init__.py
Especially interesting function: appmenus_create.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYWyosAAoJENuP0xzK19csMJIH/jlKc6O7C2UvCaNyTF7abJRm
kTDLVj9bM5M7LisfblTt3fFUvem6nneOiHf6760coX1Mjet/5w7TlH8rAShUO6Dn
/D19P0mCu1N/kyZLqzNa65Wm1pAYxYC7NFxVt4pxYoOnImaFZJM8SU+Q6QburcJp
Sh0gC5aJdMfQNzViJja2z9NkR5fxBApk0QlyMaSbqBtlugp0oBAa1hu3waiixcDf
Flfi5cPLRKxVjrbU2nHE4tnuW4ZuXdPb77LGVtxmBdaf/Co7UV9OTj3S+joTIg6a
WqPCztX7cMwueNI3X0yolJeSSCI553iKdLlqWAAOjtYkSPB4fGb0jyAplObJG7Y=
=yZob
-----END PGP SIGNATURE-----

[Jean-Philippe Ouellet]

On Wed, Dec 21, 2016 at 8:19 PM, Marek Marczykowski-Górecki
<marm...@invisiblethingslab.com> wrote:
> 1. Have apps.templates and apps.tempicons (icon templates) directories
> in every VM (/var/lib/qubes/*/*), not only templates. For templates sync
> them from /usr/share/applications, for non-templates sync them from
> /usr/local/share/applications.

And ~/.local/share/applications too?

> 2. While creating (or listing for Qubes Manager) .desktop files, first
> look into AppVMs own apps.templates, then fallback to the one from VM
> template. Same for apps.tempicons.

If by "fallback" you actually mean "also include" rather than "only
include if the first does not exist or is empty", then I agree.

> 3. In any case, create .desktop files in apps directory of the VM
> itself.
>
> Unanswered question: how to deal with /usr/local/share/applications in
> the template itself? According to the above algorithm, it will be
> ignored. I don't see any use case for template-only application
> (installed into /usr/local there). But surely somebody will trip over it,
> sooner or later.

The template's /usr/local is hidden by being mounted over by the
appvm's /rw/usrlocal anyway, so IMO this is not an issue to be
concerned about.

> Am I missing anything else?

~/.local/share/applications ?

I had forgotten about it initially too.

> BTW Here is the code for Qubes 4.0:
> https://github.com/marmarek/qubes-core-admin-linux/blob/core3-devel/qubesappmenus/__init__.py
> Especially interesting function: appmenus_create.

I should really build myself a 4.0 installation and start hacking on
that instead...

[Jean-Philippe Ouellet]

On Wed, Dec 21, 2016 at 9:13 PM, Jean-Philippe Ouellet <j...@vt.edu> wrote:
> On Wed, Dec 21, 2016 at 8:19 PM, Marek Marczykowski-Górecki

>> Unanswered question: how to deal with /usr/local/share/applications in
>> the template itself? According to the above algorithm, it will be
>> ignored. I don't see any use case for template-only application
>> (installed into /usr/local there). But surely somebody will trip over it,
>> sooner or later.
>
> The template's /usr/local is hidden by being mounted over by the
> appvm's /rw/usrlocal anyway, so IMO this is not an issue to be
> concerned about.

Although an AppVM's /rw/usrlocal appears to be copied from the
contents of the template's /usr/local at time of AppVM creation, so
maybe this is an issue after all...

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Wed, Dec 21, 2016 at 09:13:53PM -0500, Jean-Philippe Ouellet wrote:
> On Wed, Dec 21, 2016 at 8:19 PM, Marek Marczykowski-Górecki
> <marm...@invisiblethingslab.com> wrote:
> > 1. Have apps.templates and apps.tempicons (icon templates) directories
> > in every VM (/var/lib/qubes/*/*), not only templates. For templates sync
> > them from /usr/share/applications, for non-templates sync them from
> > /usr/local/share/applications.
>
> And ~/.local/share/applications too?

Yes.

> > 2. While creating (or listing for Qubes Manager) .desktop files, first
> > look into AppVMs own apps.templates, then fallback to the one from VM
> > template. Same for apps.tempicons.
>
> If by "fallback" you actually mean "also include" rather than "only
> include if the first does not exist or is empty", then I agree.

Yes. With preference of VM-specific files.

> > 3. In any case, create .desktop files in apps directory of the VM
> > itself.
> >
> > Unanswered question: how to deal with /usr/local/share/applications in
> > the template itself? According to the above algorithm, it will be
> > ignored. I don't see any use case for template-only application
> > (installed into /usr/local there). But surely somebody will trip over it,
> > sooner or later.
>
> The template's /usr/local is hidden by being mounted over by the
> appvm's /rw/usrlocal anyway, so IMO this is not an issue to be
> concerned about.

But the template's /usr/local lives in its /rw/usrlocal, so in general
isn't shared. With the exception it's copied at VM creation time - this
will change in Qubes 4.0.

> > Am I missing anything else?
>
> ~/.local/share/applications ?
>
> I had forgotten about it initially too.
>
> > BTW Here is the code for Qubes 4.0:
> > https://github.com/marmarek/qubes-core-admin-linux/blob/core3-devel/qubesappmenus/__init__.py
> > Especially interesting function: appmenus_create.
>
> I should really build myself a 4.0 installation and start hacking on
> that instead...

:)

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYW080AAoJENuP0xzK19csATkH/1OuJjlZJC6cH9b4I9ycLNsq
pWTv7khzWOMSF8h/In8Zzx0UY63FHkq3ngH0eeIND7AyGt3JO1ATHu1853iHrFZ+
Z2y/5mNQZMYsehp1q4360864oZwhsN7AbPCliwl3BCAzbwDqVCf2xljVXgWidQB1
Rm41WhE3EMa2O+x0Xag4XtTrE6hUScDXVBcpohdJMznbJlFmI9mklWqavCZ0m1+L
hFNqNysPUkuWNU5iqYMxHJ0w3L1dA3iNL60tJ8EjLu/ULPo3+Np1G/tFMCxaK3/r
wL4swo0oJeNFk8OtWR720xshfwwMmengOdq2Mh6eUQhNvwLeDRJrzh+f1e4tGNw=
=wjxx
-----END PGP SIGNATURE-----

[Patrick Schleizer]

Wondering how this works as per non-Qubes, plain Debian upstream default?

Does /usr/local/share/applications even get parsed?

How is ~/.local/share/applications being processed?

- Does ~/.local/share/applications/some-file.desktop overwrite or extend
/usr/local/share/applications/some-file.desktop?

-- I mean, does ~/.local/share/applications/some-file.desktop have to be
a complete file as in /usr/local/share/applications/some-file.desktop is
totally disregarded?

-- Or does it work more like systemd drop-ins, more like extensions,
where one could just add a single line into
~/.local/share/applications/some-file.desktop such as 'Exec=...' that
would overwrite only that one line from
/usr/local/share/applications/some-file.desktop?

Should the Qubes implementation be similar to that?

Best regards,
Patrick

[Patrick Schleizer]

Marek Marczykowski-Górecki:

> Am I missing anything else?

Glad you are asking! :)

> I don't see any use case for template-only application
> (installed into /usr/local there). But surely somebody will trip over it,
> sooner or later.

In fact, we at Whonix just recently discussed upon a use case for
TemplateVM /usr/local/share/applications so to speak. That is, firejail
confinement.

For example to enable firejail for firefox one would have to edit
/usr/share/applications/firefox-esr.desktop and modify the Exec line to:
Exec=firejail /usr/lib/firefox-esr/firefox-esr %u

We should avoid editing /usr/share/applications/firefox-esr.desktop
directly - because next time firefox is updated (can happen also in
Debian stable during firefox security upgrades) - modifications are
lost. (Firejail containment gets lost far too easy. And no longer using
it at some point is as good/bad as never using it.)

So where could we drop the .desktop file override?

/usr/local/share/applications/firefox-esr.desktop ? - but you said,
/usr/local won't be inherited by TemplateBasedVMs in Qubes 4.0. [Which
makes sense.]

~/.local/share/applications/firefox-esr.desktop in TemplateBasedVMs? -
Not great, because that would have to be done in every TemplateBased AppVM.

I don't think the firejail use case is covered anywhere.

Would we have to invent some non-standard folder to cover that use case?
For example some file
/usr/share/applications-overrides/firefox-esr.desktop in root image?

Best regards,
Patrick

[WillyPillow]

Regarding Firejail, I personally use it with Firefox on my VMs. For the shortcuts I just make a copy of

/usr/share/applications/firefox-esr.desktop

to

/usr/share/applications/firefox-firejail.deskop

and modify the Exec line along with the program name (i.e. Firefox -> Firefox With Firejail).

This way, it is unlikely to be overwritten by updates, and is easily verified by checking the program name.

Of course, updates modifying the .desktop file will not apply to the custom shortcut, but in the case of most applications, this (IMO) doesn't matter too much.

--WillyPillow