Hey!
I’m snapping an application that use interprocess tools from boost (boost::named_mutex, boost::named_condition).
Processes that I want to synchronise are all in this snap.
When I try to create such objet I always catch an exception “Permission denied”.
I try to enable the following interfaces: plugs: [network, netwok-bind, process-control, system-observe]
but it doesn’t seem to help.
Do you know which plug should I activate? Is there other solution to use interprocess mecanism with a snap?
Note that you can also use the ‘snappy-debug’ snap (sudo snappy-debug.security scanlog) and it will make suggestions.
The shm denials are covered here: Shared memory in /dev/shm rewriting. Does using the snapcraft preload part resolve this? Otherwise you could update the source to for it to use snap.$SNAP_NAME.XXXXXX (eg, conditional on if SNAP_NAME is set).
Note: I just now updated snappy-debug to suggest snapcraft preload
I’m pretty new at snapping and I have never use snappy-debug.
If I run my program as usual everything is ok, and the other and if I run it with snappy-debug my program freeze, nothing and the shell and I have to kill (Ctrl+C) to quit.
you do not usually “run an app with” snappy-debug, just run your app normally so that it logs the issues that happen into syslog/journal … after you ran your app you run:
sudo snappy-debug.security scanlog
and snappy-debug will scan the log and make suggestions about the logged issues …
Ok, after some reshearch I found that the renaming come from the implementation of open_sem() in glibc.
Thanks:
When creating a file on /dev/shm glibc start by creating a random file and if everything is ok link the random file to the requested one.
My problem is that I don’t I the right to create the random file.
My question is: am I allowed to create a file called “snap.blabla” in /dev/shm/ ? If yes who is giving me this right? And why i creating a file named “blabla” is forbidden ?
/dev/shm/snap.$SNAP_NAME.* is supposed to be a subdirectory, not a file (@jdstrand i think the snappy-debug text should be clearer there)
in general snapd disallows accessing /dev/shm/, snaps could spy on each other through that.
so snapd makes sure each snap gets a subdir on its own where it can drop in its named semaphores instead …
and for this you need the preloading, it will intercept the function and use the subdir instead of directly trying to write to /dev/shm … the alternative would be to patch your app everywhere it uses that function and hardcode that dir … but thats not really feasable …
@thooxx - yes, you are allowed to create /dev/shm/snap.blabla.ANYTHING, where ‘blabla’ is your snap name (note that the ‘.’ after ‘blabla’ is important).
Adding a prefix “snap.$SNAP_NAME.” for all named mutex in my app is not a problem but it’s not the solution.
I’m stuck with glibc that create a temporary file with a random name in the /dev/shm directory and this action is not catched by the preload scnapcraft.
i don’t know preload snapcraft woks, one solution could consiste on overiding the function that provide the shm directory but i don’t know if it can be done.
const char *
__shm_directory (size_t *len)
Unfortunatly, I think snapd is not mature enought for me …
I was looking into this problem and it’s not an easy fix unfortunately. I’ll talk to the snapd team and see if we can make something that we could deploy for everyone in general.
