Snap interface for /dev/shm

Which variation of
snap connect _mysoftware_:_myinterface_
allows access to /dev/shm ?

The list at https://docs.snapcraft.io/reference/interfaces does not seem to contain any reference (to “shm”).

Long story: I just installed the Gimp on a new (X)Ubuntu 18.04 LTS.
Got puzzled as the Gimp refused to open the image to operate on, placed in /dev/shm . I always use /dev/shm as a store for all temporary files to be re-worked.
Got even more puzzled as the Gimp could not open images in the mounted drives (/media/…).
Searched for hints. Found a suggestion about “snap connect gimp:removable-media”. Wondered. Did a snap list, and got a confirmation that the current Ubuntu installs the Gimp as a snap package. Welcome snap.
So a snap connect gimp:removable-media solves accessing the /media/ filesystem branch.
But I cannot see a way to access /dev/shm - which is my workspace.

Snaps are purposefully only allowed to access /dev/shm through files with a naming pattern of /dev/shm/snap.<snapname>.*. This is to prevent one application from interfering with any other applications on the same system. There are no interfaces to expose other files in /dev/shm.

1 Like

There are no interfaces to expose other files in /dev/shm/

Exactly. And the problem is, such interface is needed. The user may easily want to access any file in /dev/shm - for example, as written, a screenshot to edit in the Gimp.
The user should not be forced to the unneeded hassle of renaming the file - I still see no real reason for it. The user, with total certainty, cannot be forced to write on disk a temporary file that can be just kept in RAM.

Now, while the matter is considered at project level - and probably fixed with minimal effort, to the best of my understanding -, can anybody please share a way to patch this behaviour? On my system, I need snap-based applications (at least surely some) to access any file in /dev/shm .

On my system, I need snap-based applications (at least surely some) to access any file in /dev/shm .

Or at least, an aptly named subdirectory in /dev/shm
(create it once, use it forever)

you can bind mount a dir to ~/ and have your apps use the home interface to read/write to that:

$ mkdir /dev/shm/shared
$ mkdir ~/shmdir
$ sudo mount --bind /dev/shm/shared ~/shmdir
$ touch ~/shmdir/foo
$ ls /dev/shm/shared/
foo
$
1 Like

bind mount a dir

In practical terms, that can be a good idea, thanks. Of course, it is a circumvention, a “”“dirty hack”"", but effective nonetheless.

To proceed more linearly, I was looking for information on how to disable the AppArmor profile.
I see that apparmor_status reveals a
snap.gimp.gimp
profile enabled in enforce mode.

I understand that

  sudo ln -s /etc/apparmor.d/{profile.name-here} /etc/apparmor.d/disable/
  sudo apparmor_parser -R /etc/apparmor.d/{profile.name-name-here}

should disable an AppArmor profile, but I cannot seem to find details of that snap.gimp.gimp in /etc/apparmor.d/ .
How to disable it?

EDIT: I was actually hoping to be able to edit the profile, but if pressed I could as well disable it.

To proceed more linearly, I was looking for information on how to [modify or] disable the AppArmor profile.

I see that niemeyer, at Shared memory in /dev/shm rewriting ,
specifies that the enforcing code is

/{dev,run}/shm/snap.@{SNAP_NAME}.** mrwlkix,

but unfortunately I do not see that in /etc/, and I find it instead in /usr/lib/snapd/snapd
which is an ELF (not, as I would have hoped, an extended-text-configuration file). Pretty difficult to edit.

I suspect there should still be a way to disable the AppArmor profile?

@mdp

The user may easily want to access any file in /dev/shm

The whole point of snap sandbox is to prevent that access :grin:
you can disable snap sandboxing by installing gimp with:
sudo snap install gimp --devmode
EDIT: Don’t do this unless you want to be immediately hacked by @daniel :joy:

If you do this, don’t complain when I inevitably turn evil and embed something into gimp that does nasties with all your files… :wink:

Seriously, though, --devmode is not meant as a bypass, it is meant as a debugging thing for developers. End users shouldn’t install snaps with that flag.

1 Like

I would really like --classic to be functioning as a switch to disable security confinement for non-classic snaps.

For the record I absolutely don’t recommend doing this but if someone is so desperate to manually disabling apparmor profiles there is no other help.

The whole point of snap sandbox is to prevent that access [to /dev/shm] :grin:

But can I ask why? I could not locate a document that justifies such purpose…
Temporary files have their most appropriate storage in volatile memory; to have your applications work on, hence of course access, files in /dev/shm is the most normal process I can think of, ranked in normality just before the other one of saving final files on persistent storage. I cannot get what alternative process the project drafter was supposing - nor what risk he tried to curb.

If you do this, don’t complain when I inevitably turn evil and embed something into gimp that does nasties with all your files… :wink:

Daniel, all of the applications access most of the filesystem, very surely files that I certainly do not want to be compromised, but this is the *nix model… Unless I created a user per file class…
Do packages access /home by default? Than any of them could act as a rogue and vandalize! Of course, if anything like that happened, that would be dire, but communications would spread pretty fast.
Now, in the case of image processors or browsers, it is very natural that they are made to access for example mounted storages (for potential bulk of their intended data), which makes them an accepted threat by their own very nature…

In snap they are stored in volatile memory too but in /dev/shm/snap.@{SNAP_NAME}.* to prevent other apps from accessing files and to prevent accessing files of other apps.

Of course not. Otherwise sandbox wouldn’t make sense.

1 Like

Of course not. Otherwise it wouldn’t make sense

Great, interesting, it is starting to make sense. In fact, I see that ‘home’ is in the list of the interfaces.
But would not it make then even more sense to give the ability to whitelist access to a list of directories?
As in: allow the Gimp (for example) access to /media/images, /dev/shm/temp_images, /home/mypictures …
I have met snap for not even one day, so I am still in the process of knowing/understanding it, but I understood that granularity of access stops at “”“big”"" categories (not at specific directories).

BTW, this would solve my case, because I would add some /dev/shm/shared to the whitelist and be happy thereafter.

BTW, this would solve my case, because I would add some /dev/shm/shared to the whitelist and be happy thereafter.

By the way2, I wanted to propose the introduction of a special directory

/{dev,run}/shm/snap.shared/.**  mrwlkix,

(I am not sure if the syntax is correct.)
Wanted, but had not: at this stage, I am not sure of what are the most sound proposals I can make.

We are researching something that will offer a feature for user-driven customization of access into individual directories, similar to what you propose. It will still take a while as we have other high priority features in front of it, but it may show up at some point.

Not clear what that gives you since you didn’t describe the semantics. But in general, any directories that are shared by default break the isolation across snaps in ways that cannot be anticipated, as others pointed out above.

1 Like

Having /dev/shm as a workspace seems quite atypical. It sounds like you are using this as /tmp?

Perhaps this helps (note that while it is titled “Ubuntu Core”, it covers also the basics of snaps and their security model) ?

1 Like

Having /dev/shm as a workspace seems quite atypical. It sounds like you are using this as /tmp?

Nice to meet you Niemeyer,
that is the idea, but /tmp , compared to /dev/shm , is slower and it uses the hard drive, which is unnecessary and oftentimes bad practice. The RAM-disk is as fast as you can get and does not strain.
Everytime I have to operate on files that require processing, and after that will be dismissed, I place them in /dev/shm (“normal practice”). You would not write them on disk, because that is unneeded, right? The same goes, especially, for files that will be subject to very frequent update and need to be processed with the highest speed (“bounded practice”).

The occasion that triggered this thread was simply the conversion of a .png into a .jpg - the .png was a fresh disposable file which I had in /dev/shm . This is a case of normal practice.

But I wish to give a couple of examples, that may show usual procedures where using some space in /dev/shm , and shared between applications, is bounded even more than normal.

Suppose you have to populate an SQLite database. Some automation will impose on it thousands or millions of committals, and as fast as possible: you place it somewhere in /dev/shm . You will store it in the hard drive only after completion. Well, you could rename it as /dev/shm/snap.myIDE.myDB - acceptable hassle, especially if you have created a renamer for these cases and placed it in the popup menu of your desktop manager (although not modifying names and placing files as they are originally named in specific directories is better: that DB you created is not for the “myIDE” application, it is prepared for other ones to use - its name will probably be pretty much constant and in general not related to “myIDE”).
Now, you may also want to check what is happening periodically while the populating process is working, with a GUI-based database manger. If the populating process, “myIDE”, and the database browser application, “myDB-GUI”, are both snap based and observing current segregation model, you cannot access the same file - not simultaneously, and not reasonably even sequentially, since this would mean renaming the file constantly, or finding some other hack.

The same metaphor can be applied to other similar cases: suppose you are extracting data from markups (XML), disposable, placed in /dev/shm to be processed, and at the same time (before, during, after), you want to check the contents with a text editor or similar…

You need the ability to have in the RAM-disk shared spaces between otherwise segregated applications. I supposed that the straightforward way would have been an interface.