Content Interface does not mount files

[James Jesudason]

From one of our customers:

As described in our last meeting we have serious problems using the content plugin.

Scenario:
We use the content interface to mount a folder from multiple Snaps into one central snap.
The central snap is providing a Plug as described in yaml:
  package-assets:
    interface: content
    content: package-assets
    target: $SNAP_DATA/package-assets

All other snaps provide a Slot as following:
  package-assets:
    interface: content
    content: package-assets
    read:
      - $SNAP_DATA/package-assets

After installation and connecting the interface works fine. mounting a directory $SNAP_DATA/package-assets-n/ in the central snap.

After a restart of the device interfaces still show connected. And the corresponindg $SNAP_DATA/package-assets folder is available, but the content is empty.

Seems like it has something to do with Apparmor, see logs attached

[James Jesudason (jamesj)]

Attached is a snippet from the log. I have a full log if needed.

[Zygmunt Krynicki (zyga)]

Reproduced.

Looking for the cause now.

[Zygmunt Krynicki (zyga)]

I understand the cause now. Looking for a solution.

[Zygmunt Krynicki (zyga)]

I have a workaround and I will work with the release manager to get this into 2.42.1

[Loïc Minier (lool)]

Thanks for the quick turnaround for a fix :-) Would you mind updating this bug when a snapd is available in edge and/or beta channels for testing? I understand that an edge build will likely happen in the next couple of days once the pull request is reviewed and merged, and that a beta/stable update would be more in the ~1/2 weeks time frame.

[Zygmunt Krynicki (zyga)]

This is fixed by the following pull request https://github.com/snapcore/snapd/pull/7677

[Zygmunt Krynicki (zyga)]

@Loic: sure, I'll send the update as soon as this is in edge.

For a priority request we can also publish the patch in a branch and that can be done extremely rapidly. We can have the fix available in several hours.

[Jochen Scheib (sjo2lo)]

Hi,
regarding your PR. You mentioned that it is a misuse of direct mode and that there is a spool mode for use cases like this. Can you provide information about the spool mode?

Thanks.

[Zygmunt Krynicki (zyga)]

@Jochen the spool mode is not documented in the proper place (snapcraft.io/docs) but it is documented on the forum in the feature discussion thread here: https://forum.snapcraft.io/t/improvements-in-the-content-interface/2387

The main difference is that the syntax changes so that slots have a "source" attribute that can have both read and write attributes with lists of paths.

slots:
  content:
    source:
      read: [$SNAP/foo]
      write: [$SNAP_DATA/bar]

The plug side syntax is the same as before.

Connecting such slot to a plug changes the semantics in one way, in the direct mode the plug target directory is used *directly* as the mount target. For example with this plug

plugs:
  content:
    target: $SNAP_DATA/here

A single direct slot defining a single directory to read or write would just get mounted over "here". In the new spool mode the directory "here" is not mounted over. Instead each element defined by all the connected slots are mounted as distinct entries inside. For example, if the slot and plug defined in this comment were connected the resulting directory tree would look like this:

$SNAP_DATA/here/foo # bind mount to other side snap's $SNAP/foo
$SNAP_DATA/here/bar # bind mount to other side snap's $SNAP_DATA/bar

The spool mode is better because you can then enumerate "here" and know what is connected reliably.

[Jochen Scheib (sjo2lo)]

Thanks for the fast response.