Semaphores and access to /dev/shm

[Alberto Mardegan]

Hi all!
  I'm working on a snap of a python2 utility which is using the Pool
class from the multiprocessing module. But this gets blocked by apparmor:

Log: apparmor="DENIED" operation="mknod"
profile="snap.bundler-mardy.bundler-py" name="/dev/shm/8sszOM" pid=17782
comm="python2" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
File: /dev/shm/8sszOM (write)
Suggestion:
* adjust program to create files and directories in
/dev/shm/snap.$SNAP_NAME.*


Unfortunately, the suggestion is not really helpful, because the
filename is not decided by the client code. But even if somehow we fixed
the python implementation to generate a proper name, it looks like
sem_open() is behaving in a very peculiar way: please have a look at
this strace log, obtained on an *unconfined* process:

=================
statfs("/dev/shm/", {...}) = 0
futex(0x7f1b658f9310, FUTEX_WAKE_PRIVATE, 2147483647) = 0
lstat("/dev/shm/ApjbNj", 0x7ffe9cefff20) = -1 ENOENT
open("/dev/shm/ApjbNj", O_RDWR|O_CREAT|O_EXCL, 0600) = 6
write(6,
"\1\0\0\0\0\0\0\0\200\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0",
32) = 32
mmap(NULL, 32, PROT_READ|PROT_WRITE, MAP_SHARED, 6, 0) = 0x7f1b65a5d000
link("/dev/shm/ApjbNj", "/dev/shm/sem.mp18207-15353487325820441356") = 0
fstat(6, {st_mode=S_IFREG|0600, st_size=32, ...}) = 0
unlink("/dev/shm/ApjbNj")               = 0
close(6)                                = 0
=================

That is, it looks like sem_open() is first creating a temporary file,
and then linking it to a file with the proper name (the python code is
using "/mp%ld-%lu" as semaphore filename). This also seems confirmed by
a quick look at glibc's source code:

http://sourceware.org/git/?p=glibc.git;a=blob;f=nptl/sem_open.c;h=a80e5b8e9b15090c2ecacb1c1e587c501cf20ffb;hb=HEAD#l277

So, it looks like sem_open() can't possibly work under confinement, or
am I missing something here?

Ciao,
  Alberto