How to autostart a snap of a desktop application?

[jdstrand]

How is th autostarted application started under confinement if there is no parsing and updating of the Exec line?

[jdstrand]

@niemeyer

We might be able to go with something simpler as you suggest, and have sane defaults. Perhaps:

apps:
  foo:
    command: foo
    autostart: foo.desktop

The semantics might be:

1. When the user session starts, look into ~/snap/*/current/.config/autostart/
2. If filename matches the value of the field in one of the snap commands, then process the file
3. The Exec line in the file is parsed out, and the snap command is run
4. If the Exec value is “some/command -a -b”, the equivalent snap command would be “snap run theapp -a -b”.

What is looking in ‘1’, userd?

This approach seems reasonable since the application itself shouldn’t need to be modified-- the snap publisher simply says ‘my snap sets up autostart using this desktop file’, then the application can write to it however it wants. userd now knows where to look for it and it will make sure that it is launched under confinement.

We need to be careful with parsing the Exec line; though, we should be able to reuse our current rewriting code. Likewise for verifying the validity of the other fields of the desktop file (ie, we want to be sure that other things in the desktop file don’t influence userd to break out).

[jdstrand]

@jdstrand

How is th autostarted application started under confinement if there is no parsing and updating of the Exec line?

Answering myself-- Gustavo outlined a plan that connected the dots, which I’ve responded to.

[chipaca]

@niemeyer I’m not sure what the advantage is of reading the file and parsing its Exec line, could you elaborate on that?

[niemeyer]

We don’t control how the file is generated. The same desktop file may be written out in various ways depending on how the application (or more likely the user) decided for it to be auto-started.

[niemeyer]

@jdstrand

We need to be careful with parsing the Exec line; though, we should be able to reuse our current rewriting code. Likewise for verifying the validity of the other fields of the desktop file (ie, we want to be sure that other things in the desktop file don’t influence userd to break out).

The parsing code ought to be the same indeed. The rest of the file isn’t so relevant here, though, because it’s userd itself that will be running the command.

[jdstrand]

@niemeyer

The parsing code ought to be the same indeed. The rest of the file isn’t so relevant here, though, because it’s userd itself that will be running the command.

That’s what I was trying to get at-- userd is unconfined so we want to make sure that other fields aren’t influencing userd in unexpected ways. If userd only looks at the Exec line, then yes, nothing else to worry about. If it starts to look at other fields, just need to be careful of what the untrusted input from the desktop file is providing.

[mborzecki]

RFC right here: https://github.com/snapcore/snapd/pull/4768 If the idea is fine, I’ll clean it up and add tests.

[mborzecki]

I’m testing with a customized discord snap. The changes I’ve made:

• renamed command-discord.wrapper → discord
• patched snap.yaml:

  diff -upr discord.orig/meta/snap.yaml discord/meta/snap.yaml
  --- discord.orig/meta/snap.yaml 2018-01-09 12:11:20.000000000 +0100
  +++ discord/meta/snap.yaml      2018-03-01 08:03:30.931442231 +0100
  @@ -11,7 +11,8 @@ confinement: strict
   grade: stable
   apps:
     discord:
  -    command: command-discord.wrapper
  +    command: discord
  +    autostart: discord-stable.desktop
       environment:
         TMPDIR: $XDG_RUNTIME_DIR
       plugs:
  

• patched discord-stable.desktop file:

  --- discord-stable.desktop.orig 2018-03-01 10:00:18.947229990 +0100
  +++ discord-stable.desktop      2018-03-01 10:00:03.166175163 +0100
  @@ -1,6 +1,6 @@
   [Desktop Entry]
   Type=Application
  -Exec=/snap/discord/x1/usr/share/discord/Discord
  +Exec=discord
   Hidden=false
   NoDisplay=false
   Name=Discord
  

@niemeyer

If the Exec value is “some/command -a -b”, the equivalent snap command would be “snap run theapp -a -b”.

Can you clarify if in some/command -a -b, the some part is an arbitrary prefix and as long as the whole line ends with command .. we count it as a match?

[mvo]

This is available with snapd 2.32.4 or later which is available in the candidate channel now.

[Ads20000]

There was a new feature made in a bugfix release?! Or was this meant to be a feature in 2.32.0 but a bug meant it wasn’t working properly?

[niemeyer]

@Ads20000 A bit late, but for the record the .N at the end stands for very low risk in snapd, rather than strictly a bug fix. In the case at hand, for example, this was a new feature that did not touch existing semantics elsewhere, so the risk of regression was very low. In some cases, we may also see slightly larger features landing in such releases if the earlier releases were blocked in testing channels (< stable) for too long, which in practice means the minor was not really released publicly yet.

[Ads20000]

To stick to SemVer would it be worth calling 2.34, when it comes, ‘2.34-rc.1’ to stick to SemVer whilst it’s still in non-stable channels? Then you could bump to 2.34-rc.2 etc and then go to 2.34 when it’s in stable? Also a possibility for the feature-releases-pretending-to-be-bugfix-releases would be releasing the next version (2.35) without all the features originally planned (pushing them back to 2.36) and then getting the release managers to promote that faster?

Just thoughts, I’m not a dev, just think that SemVer is very neat. Perhaps it is OK to do some very minor releases as bugfix releases as long as that’s carefully monitored and not allowed to allow bigger and bigger features as ‘bugfixes’…

[kyrofa]

Do we have any docs for how this works?

[mborzecki]

It’s described under app properties right here:

The snap format

This page documents the format of the built snaps. See The snapcraft format for more information about the snapcraft.yaml file used to build these snaps. A snap is a SquashFS file carrying content alongside metadata to tell the system how it should be manipulated. When installed, the SquashFS file for the snap is mounted read-only at the following location: /snap/<snap name>/<revision>/ This method delivers fast and extremely predictable installations, with no installat…

I see now that the description a bit brief, I’ll extend it a little.

[alexmurray]

I realise this is a bit late in the piece but I wonder if instead of having userd launch the app, why not instead when the snap is installed, install symlinks in $HOME/.config/autostart/xxxx.desktop -> $HOME/snap/xxxx/current/.config/autostart/xxxx.desktop - then the usual session launcher can start the app rather than having userd need to do it via the symlinked desktop files (which may or may not actually exist)? This way the app would get listed in GNOME Tweaks / whatever the usual way users choose to autostart apps, as currently if a snap is autostarted via userd this is invisible to the normal app autostart bits.

[mborzecki]

It has been a while, but IIRC the motivation was that we do not allow snaps to just dump the files in $HOME/.config/autostart (as in the real user’s $HOME), but instead each snap is presented with $HOME pointing to ~/snap/<snap>/current, which AFAIK is not looked into by any of the session startup helpers.

We could work around that by having snap userd create the symlinks, but that comes with yet another potential problem, userd would have to run early in the session startup to generate the symlinks before those are looked at by the session startup. When working autostart, I explored this path and could get it to sort-of work when I used a systemd user unit for userd, but it seemed as a less than optimal solution at the time.

However, I agree not being able to disable given app is potentially a problem. Wondering if there’s something we could do something about that.

[alexmurray]

I was assuming that the snap launcher would install the symlinks when it first runs the app, or perhaps snapd could do it when installing the application?

Or we just patch gnome-tweaks etc to look for them the same way userd does currently so it can present them to the user?

[mborzecki]

@alexmurray

I was assuming that the snap launcher would install the symlinks when it first runs the app, or perhaps snapd could do it when installing the application?

We do not set up any snap apps to be autostarted by default. It is expected that the app requires a user action (a checkbox you need to tick?) to trigger the file to be dumped at the right location. I would be pretty annoyed if just installing skype snap would make it start always when I log in.

@alexmurray

Or we just patch gnome-tweaks etc to look for them the same way userd does currently so it can present them to the user?

Sounds like an easy workaround. I would expect some bugs from apps that do not look at whether their autostart file is present or record the state of user’s choice separately and that becomes out of sync once gnome-tweak disables/removes the desktop file. Though, this is not snap specific and would behave the same if app came from the usual packaging.

[jdstrand]

@alexmurray (cc @mborzecki): we don’t want symlinks from ~/.config/autostart into the snap’s area because the snap could adjust the desktop file’s Exec line to not run under confinement. The behavior is what it is in part to ensure that there isn’t a sandbox escape (userd rewrites the desktop file).