Recently, we have added new policies to support IPC usecase. However, there is no CI test that checks the scenario.
Let's add one such scenario to the gating tests.
Testing scenario
The socket needs to be created at (currently):
/run/ipc-demo/ipc.socket
Two containerized application shall mount the volume containing the socket and communicate. There are many interesting cases here, ASIL-QM communication probably is the most as it is also the most complex.
What we need
A containerized application running on the Safety layer.
SecurityContextLabel=ipc_t
A containerized application running on the QM layer.
SecurityContextLabel=qm_container_ipc_t
A systemd.socket file to create the socket at startup.
This is a nice way as otherwise we would need to create the subfolder in the /run/ipc directory before mounting the volume in the containers. And then one of the containerized application (the server-side), would need to create the socket file.
Description
Recently, we have added new policies to support IPC usecase. However, there is no CI test that checks the scenario.
Let's add one such scenario to the gating tests.
Testing scenario
The socket needs to be created at (currently):
/run/ipc-demo/ipc.socket
Two containerized application shall mount the volume containing the socket and communicate. There are many interesting cases here, ASIL-QM communication probably is the most as it is also the most complex.
What we need
SecurityContextLabel=ipc_t
SecurityContextLabel=qm_container_ipc_t
A systemd.socket file to create the socket at startup.
/run/ipc
directory before mounting the volume in the containers. And then one of the containerized application (the server-side), would need to create the socket file.[Socket] ListenStream=%t/ipc-demo/ipc.socket RuntimeDirectory=ipc-demo SELinuxContextFromNet=yes
[Install] WantedBy=sockets.target
Drop-in configuration to extend qm settings: