Glob patterns with the system-file interface

Without going into too much detail, our software needs permission to create directories with random UUID’s. This means that we can’t simply ask for permission to read/write to hard-coded filepaths.

We know that AppArmor allows for glob patterns. When we overwrite the AppArmor profile for our snap, we’re able to get our software working by writing a simple pattern to match the uuid directory.

However, we’re not able to do this through the snapcraft.yaml file. The system-files plug doesn’t allow for glob patterns because * is a reserved AppArmor character.

We know that the filesets can be used to create globs for parts. How would we do this for an app or plug? If it’s possible to do this right now, the syntax is unclear.

system-files can be used to specify a directory, in which case everything under it will be allowed.

Eg, consider:

/foo
/foo/bar
/foo/baz
/foo/corge/norf

For read-only access, you might use:

plugs:
  foo:
    interface: system-files
    read:
    - /foo

which gives the following AppArmor rule under the hood:

  "/foo{,/,/**}" rk,

granting read access to the file /foo, the directory /foo/ and all files and directories under /foo such that the above example file hierarchy is allowed.

That would work, but the directory I’d need to access is /, so I’d be asking for a lot more privilege than I need.

The filepath would be something like /<UUID>/...

This isn’t really what system-files is for since, for example, /<UUID>/ is not in the runtime environment of the snap. This is also not FHS-compliant. You could use /var/lib/snapd/hostfs which is / on the hosts and it would ‘work’, but this wouldn’t be allowed in the store since it grants access to everything (and again, abuse of the interface). If you only need read access, you could use the system-backup interface, but that would grant read access to most of the host.

Why are the files in /<UUID>/? Are these symlinks? What system is this on? Can you describe in more detail what this is for?