Recursive mounts in content interface for themes

#1

Hey there,

That’s another issue we are having with the content interface in context of getting themes to work with snaps.

In the case where the gnome platform snap is being used we have that configuration

theme_snap

that snaps includes a slots giving read access to the theme directory

gnome_platform_snap

the platform is mounting the themes so those apps don’t have to care about the technical details, which means

  • the platform has a plug mounting the theme
  • the platform has a slot that gives read access to its content
  • the theme is in a subdirectory of the platform shared directory

client_snap

the client snap mounts the platform

so in summary

[gtk_software_snap, gnome plug] -----> [gnome slot, gnome_platform_snap, theme plug] -> [theme slot, theme_snap]

But it looks like the gtk snap doesn’t see the content of the theme, the gnome platform content is correctly mounted but it includes a theme directory which seems to be only the empty mountpoint and not have the content of the theme snap.

Does anybody know if that’s the expected behaviour or a bug? If so in what component?

Thanks,

Sebastien Bacher

Ubuntu Desktop Team Priorities
#2

The reason it is happening is because connecting the content interface does the equivalent of mount --bind, which only binds a single file system: not any of the file systems mounted underneath that source directory. The behaviour you want is that provided by mount --rbind (recursive bind).

The open question then is when should the content interface use a recursive bind mount?

  • Always?
  • Only when the slot requests it?
  • Only for a privileged snap?

I’m not really sure what the security implications of a change like this are.

#3

During the sprint last week we discussed quite a few issues related to themes. Ideally we’ll come up with an underlying solution that works for all distributions so we don’t need to cook per-distribution themes, which means we probably don’t want to tie the platform snap to the themes directly. We also need to plan for the upcoming breaking changes, and how we’ll evolve these in a way that continue to work as the multiple dimensions continue to move forward (gtk, the distributions, glibc, gcc, etc).

There are preliminary notes in this whiteboard picture in the sprint topic:

But that’s both too vague and indeed preliminary. We need to sit down and come up with a more complete picture of how we want themes to work under those terms.

#4

Yeah, that’s tricky because I think it will be difficult to know what order to mount things too. If we were going to consider rbind, we’d want very specific use cases so we could better understand where we want to go. Themes may or may not be that use case…