FastDDS SHM permission issue

[fenggaobj]

FastDDS 2.9.1 supports the SHM function, and the SHM file name used for PDP discovery is fixed. For example, if the domain id is 0, the file used for PDP discovery is named "/dev/shm/fastrtps_port7400". If umask is set to 002, the "fastrtps_port7400" file can only be accessed by one GID, and PDPs with other GIDs will fail multicast. How should FastDDS handle this, or are there any good suggestions?

[JesusPoderoso]

Hi @fenggaobj, thanks for using Fast DDS.
Fast DDS 2.9.x is EOL, could you check if this issue persists in the currently supported branches (preferably latest v2.14.3 version)?

[gavanderhoorn]

I believe I'm running into a similar/related issue (SHM segments created by multiple different user accounts), but I'm a ROS 2 user (so using rmw_fastrtps). As that's still FastDDS, I'm wondering whether it's ok to tag along here?

Processes started by different user accounts can't seem to communicate when SHM is enabled, unless accounts are in the same group and write permission is added for the group on the SHM files (as a test I did this manually).

Being able to use SHM across different user accounts would be valuable. Is file permission a 'stupid' approach?

[JesusPoderoso]

Hi @gavanderhoorn, launching any node with a higher privileged user can lead to communication problems, as nodes run by non-privileged users may not be able to write into the memory segment.
If all users have the same permissions, as you mentioned, there is no problem.

[gavanderhoorn]

Thanks for getting back to me.

launching any node with a higher privileged user can lead to communication problems, as nodes run by non-privileged users may not be able to write into the memory segment.

yes, that's indeed what we experienced.

thing is though -- which I guess is what the OP (ie: @fenggaobj) also (implicitly) suggests -- if the segments are created as owned by a group and the access permissions are something like ...-rw-..., it can work. Manually changing the permissions of existing shared memory segments confirms this.

So my question would be: is there already a way to configure FastDDS to use a specific umask and uid:gid for the segments it creates, or would that be something that could be added?

(it's completely normal for FastDDS to not do this by default of course, as you typically don't want anyone to have access to your files in /dev/shm, but in this case I believe it would be a good feature)

[MiguelCompany]

So my question would be: is there already a way to configure FastDDS to use a specific umask and uid:gid for the segments it creates, or would that be something that could be added?

No, there is currently no way of configuring the permissions for the segments being created.
It is something that could be added (at least setting the permissions), since we use boost interprocess under the hood, and it provides mechanisms to specify the permissions when creating the segments and named mutexes.

While I agree it would be a nice feature, I don't know when we'll have resources to assign to it.
If you want to contribute the changes, we'll be happy to review them.
I would start by looking at the constructors of SharedSegment here, as well as the creation of named_mutex objects on that same file.
A nice approach would be to read an environment variable with SystemInfo::get_env, and pass the permissions depending on its value.

If you are willing to fund the effort, you could contact our commercial support

[fenggaobj]

Thank you all for your help and suggestions. We will try to use the method of environment variables to modify the permission attributes through boost::interprocess::permissions when constructing SharedSegment.