Comment 8 for bug 1578217

I had a look at this last night and IMHO there's no easy way to solve this without expanding the kernel security features. My ideas fall into the following buckets:

1) Patching various pieces of software to understand $SNAP_NAME and use it for constructing shm_open() requests. The current confinement does allow /dev/shm/$SNAP_NAME.* which maps to C code like this:

int snap_aware_shm_open(const char *name, int oflag, mode_t mode)
{
  char *snap_name = getenv("SNAP_NAME");
  if (snap_name != NULL) {
    char shm_name[PATH_MAX];
    if (snprintf(shm_name, sizeof shm_name, "%s.%s", snap_name, name) < sizeof shm_name) {
      return shm_open(shm_name, oflag, mode);
    }
    errno = EOVERFLOW;
    return -1;
  } else {
    return shm_open(name, oflag, mode);
  }
}

This code provides an alternative to shm_open that is aware of snappy requirements. What this doesn't solve is any kind of use of shared memory as an IPC system as two interacting programs will attempt to open different names. On the up side this doesn't cause any issues for applications in one snap. I think this is interesting and worth exploring as it might "unbreak" a large class of programs.

2) Patching glibc to do something like this transparently. This is much more invasive as it breaks the IPC assumption. The up side is that it might have a chance to fix pre-built binary programs that people often use through snapcraft.

3) Patching the kernel to tag SHM memory segments with apparmor labels so that they can have any name and so that the actual label is what we can build confinement around.

Let me know if you want me to investigate this in more depth.