Sublime Forum

Snap with strict confinment



Based on this code I’m trying to create a snap package but with strict confinement.

When I try I get the following error:

Mar 03 16:10:46 hostname kernel: audit: type=1400 audit(1614787846.542:126807): apparmor=“DENIED” operation=“mknod” profile=“snap.sublime-text.subl” name="/dev/shm/122560:subl_api_send" pid=122560 comm=“sublime_text” requested_mask=“c” denied_mask=“c” fsuid=1000 ouid=1000

As shown in /var/lib/snapd/apparmor/profiles/snap.sublime-text.subl these are the allowed files on /dev/shm using strict confinement:

App-specific access to files and directories in /dev/shm. We allow file
access in /dev/shm for shm_open() and files in subdirectories for open()
bind mount not used here (see ‘parallel installs’, above)
/{dev,run}/shm/snap.@{SNAP_INSTANCE_NAME}.** mrwlkix,
Also allow app-specific access for sem_open()
/{dev,run}/shm/sem.snap.@{SNAP_INSTANCE_NAME}.* mrwlk,

Can you add support for strict confinement ?



Using the snap naming convention for all shared memory files we open doesn’t make sense in the general case. To me this looks like an oversight in snap’s design, forcing every application to implement snap-specific naming when using shared memory. There’s exceptions in snap’s shm rules just to support web browsers. Here’s a proposal from 2018 to fix this in snap.

Considering that plugins that rely on other processes (like LSP) and build systems in general wouldn’t function within a sandbox I also don’t see much point in having any isolation.



Thanks, I need isolation to run Sublime in my work environment. So I was thinking that just appending an environment variable to the shared memory files would allow me use it!



You can use the workaround described here:



The workaround is for the user, so it can share files with other apps using shared memory