ice_access_control🔗
Introduction🔗
This example demonstrates how access rights can be applied to shared memory segments on Linux-based operating systems. It provides a custom RouDi, a radar and a display application.
Hint
The access right feature is only supported on Linux and QNX
Expected output🔗
Code walkthrough🔗
RouDi needs to be able to send a SIGKILL signal to the apps in case RouDi is shutdown. Hence, RouDi needs CAP_KILL capability or similar rights on other POSIX operating system. However, the user roudi does not need root access rights.
The system user can be member of multiple system groups. This examples uses the following users and groups:
| Users | privileged group | unprivileged group | infotainment group | iceoryx group |
|---|---|---|---|---|
| perception | X | X | ||
| infotainment | X | X | X | |
| roudi | X | |||
| notallowed | X |
Hint
To be able to use iceoryx communication all apps have to be in the group iceoryx.
Overview over the Apps and Shared Memory Segments🔗
RouDi is built with two shared memory segments infotainment and privileged. On startup, it creates these two shared memory segments in the operating system. The privileged segment requires the app to be started with the group privileged if it publishes data or with the unprivileged group when data should only be received. The infotainment segment on the other hand requires only one group for reading and writing called infotainment. See the next chapter for a detailed description on how to configure the shared memory segements.
+-----------------------+
+--------------------+ | | +---------------------+
| Radar App | | Privileged Shared | | Cheeky App |
| user: perception | | Memory Segment | | user: notallowed |
| | publish | | | # # |
| # | -------> | r group: unprivileged | | # # |
| # | | w group: privileged | | # # |
| # | | | | # # |
| # # | | | | # # |
| # # | | | | # # |
+--------------------+ | | +---------------------+
+-----------------------+
|
| subscribe
+---------------------------+
|
|
|
\ /
+-----------------------+
| | +---------------------+
| Infotainment Shared | | Display App |
| Memory Segment | publish | user: infotainment |
| | <------ | |
| r group: infotainment | | # |
| w group: infotainment | | # |
| | | # |
| | | # # |
| | | # # |
| | +---------------------+
+-----------------------+
RouDi and Apps🔗
Working setup🔗
Do the following to configure shared memory segments when building a custom RouDi:
iox::RouDiConfig_t roudiConfig;
// Create Mempool Config
iox::mepoo::MePooConfig mepooConfig;
// We only send very small data, just one mempool per segment
mepooConfig.addMemPool({128, 1000});
// Create an Entry for a new Shared Memory Segment from the MempoolConfig and add it to the RouDiConfig
// Parameters are {"ReaderGroup", "WriterGroup", MemoryPoolConfig}
roudiConfig.m_sharedMemorySegments.push_back({"unprivileged", "privileged", mepooConfig});
roudiConfig.m_sharedMemorySegments.push_back({"infotainment", "infotainment", mepooConfig});
The roudiConfig is composed of a memory pool config called mepooConfig. When the segement is created, one needs to
specific the reader group (first string), writer group (second string) as well as the mepooConfig (last parameter).
The access rights are solely based on user groups and not on users itself. All users in the reader group are allowed to read, but don't have write access. Users in the writer group have both read and write access.
Tip
Shared memory segment can also be configured via a TOML config file.
The radar app is started with the user perception, which is in the group privileged. Therefore it has write access to the privileged segment and is sending data into the privileged shared memory segment.
The display app is started with the user infotainment, which is in the group infotainment and unprivileged.
Therefore it has read access to the privileged segment. It reads the topic {"Radar", "FrontLeft", "Object"} from
the privileged segment and forwards it as a slighty modified topic {"Radar", "HMI-Display", "Object"}. Because
the user infotainment is only in the infotainment and unprivileged group, it only has write access to the
infotainment segment. Hence, the data is written to this segment.
Hint
It's advised to create per writer group only one shared memory segement (e.g. not two segements with w: infotainment).
In this case it wouldn't be possible to control which segment will be used.
The shared memory segments can be found under /dev/shm
moss@reynholm:$ getfacl /dev/shm/*
# file: dev/shm/iceoryx_mgmt
# owner: roudi
# group: iceoryx
user::rw-
group::rw-
other::---
# file: dev/shm/infotainment
# owner: roudi
# group: iceoryx
user::rw-
group::rw-
group:infotainment:rw-
mask::rw-
other::---
# file: dev/shm/privileged
# owner: roudi
# group: iceoryx
user::rw-
group::rw-
group:privileged:rw-
group:unprivileged:r--
mask::rw-
other::--
Note
Note the shared memory managment segment (iceoryx_mgmt) is always available for everyone in the group iceoryx
to read and write.
Not-working setup🔗
The cheeky app is started with the user notallowed. This user is not in any group that would allow him either read or write access to one of the shared memory segments. Hence, RouDi will print a warning in this case.
Despite having no read access, subscribers can still be created.
iox::popo::Subscriber<RadarObject> subscriber({"Radar", "FrontLeft", "Object"});
When creating and requesting a publisher RouDi will answer with an error, as there is no write access. Hence, an error will be printed and the cheeky app will stop.
iox::popo::Publisher<RadarObject> publisher({"Radar", "FrontLeft", "Object"});