Semaphores and access to /dev/shm

[Alberto Mardegan]

On 09/02/2017 02:22, Jamie Strandboge wrote:
> I confirmed this works fine under confinement (return code checking omitted for
> clarity):
> 
>    char *name = "/dev/shm/sem.snap.foo.bar";
>    open(name, O_CREAT | O_EXCL | O_RDRW, S_IRUSR | S_IWUSR);
>    sem_open("snap.foo.bar", 0);
> 

Argh, it doesn't work :-(

I modified Sergio's preloader (my branch is at [1]) but unfortunately
the situation is more complicated than that: yes, the code you wrote
above works, but it doesn't create a valid semaphore.
Calling sem_post on such a semaphore generates a bus error, because
sem_open() properly initializes the semaphore structure on the shm file
only when O_CREAT is passed.

I now understand why glic's implementation first creates a tmp file and
then links it: it's a way to atomically initialise the semaphore data.
The data gets first written into the tmp file, and the link happens when
it's ready.

I guess a solution to workaround the confinement would be to modify
glibc's code to not just use a completely random filename mkstemp, but
rather

   __mktemp("sem.snap.foo.bar.XXXXXX")

Though, even if this gets accepted upstream, it will take time to
appears in distros, and snaps using this feature will not work under
confinement in those distros where this has not been released yet.

Just wondering, how many kittens would die if we added a rule to allow
every snap to create/read/write files named /dev/shm/...... (six chars)?

I will try to embed a "fixed" version of glibc's sem_open into Sergio's
preloader, but I wonder if we should try to find a solution even for
those programs that don't use it.

Ciao,
  Alberto

[1]: https://github.com/mardy/snapcraft-preload/tree/sem_open


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/snapcraft/attachments/20170210/5b32e0a1/attachment.sig>