Fix: sessiond: fs.protected_regular sysctl breaks app registration

Fix: sessiond: fs.protected_regular sysctl breaks app registration

I observed that userspace tracing no longer worked when an
instrumented application (linked against liblttng-ust) was launched
before the session daemon.

While investigating this, I noticed that the shm_open() of
'/lttng-ust-wait-8' failed with EACCES. As the permissions on the
'/dev/shm' directory and the file itself should have allowed the
session daemon to open the shm, this pointed to a change in kernel
behaviour.

Moreover, it appeared that this could only be reproduced on my
system (running Arch Linux) and not on other systems.

It turns out that Linux 4.19 introduces a new protected_regular sysctl
to allow the mitigation of a class of TOCTOU security issues related
to the creation of files and FIFOs in sticky directories.

When this sysctl is not set to '0', it specifically blocks the way the
session daemon attempts to open the app notification shm that an
application has already created.

To quote a comment added in linux's fs/namei.c as part of 30aba6656f:

```
Block an O_CREAT open of a FIFO (or a regular file) when:
  - sysctl_protected_fifos (or sysctl_protected_regular) is enabled
  - the file already exists
  - we are in a sticky directory
  - we don't own the file
  - the owner of the directory doesn't own the file
  - the directory is world writable
```

While the concerns that led to the inclusion of this patch are valid,
the risks that are being mitigated do not apply to the session
daemon's and instrumented application's use of this shm. This shm is
only used to wake-up applications and get them to attempt to connect
to the session daemon's application socket. The application socket is
the part that is security sensitive. At worst, an attacker controlling
this shm could wake up the UST thread in applications which would then
attempt to connect to the session daemon.

Unfortunately (for us, at least), systemd v241+ sets the
protected_regular sysctl to 1 by default (see systemd commit
27325875), causing the open of the shm by the session daemon to fail.

Introduce a fall-back to attempt a shm_open without the O_CREAT flag
when opening it with 'O_RDWR | O_CREAT' fails. The comments detail the
reason why those attempts are made in that specific order.

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>