Can the iox-roudi service skip the user/group level when starting pre-allocated memory

[YeahhhhLi]

Brief feature description

In our usage scenario (communication with cyclonedds shm), sub-service A starts normally, while sub-service B starts with sudo, and the iox-roudi service cannot provide services for these two scenarios at the same time. In order to ensure the normal use of sub-service B, iox-roudi also needs Start with sudo.

So I guess that iox isolates users/groups. I would like to ask if there is a way to solve this problem, such as through iox configuration?

my configuration:

[general]
version = 1

[[segment]]

[[segment.mempool]]
size = 1088
count = 512

[[segment.mempool]]
size = 16448
count = 1024

[[segment.mempool]]
size = 262208
count = 256

[[segment.mempool]]
size = 1048640
count = 256

[[segment.mempool]]
size = 4194368
count = 256

[[segment.mempool]]
size = 8388672
count = 128

When service A starts with sudo and iox-roudi starts normally, an error is reported:

2022-12-19 15:55:25.507 [Warning]: Process cannot send message over communication channel
2022-12-19 15:55:25.507 [Warning]: ICEORYX error! POSH__ROUDI_PROCESS_SEND_VIA_IPC_CHANNEL_FAILED
/root/iceoryx/iceoryx_hoofs/source/posix_wrapper/unix_domain_socket.cpp:367 { iox::cxx::expected<iox::posix::IpcChannelError> iox::posix::UnixDomainSocket::initalizeSocket() -> iox_connect }  :::  [ 13 ]  Permission denied
permission to create unix domain socket denied "/tmp/iceoryx_rt_1312_1671436518216473058"
/root/iceoryx/iceoryx_hoofs/source/posix_wrapper/unix_domain_socket.cpp:238 { iox::cxx::expected<iox::posix::IpcChannelError> iox::posix::UnixDomainSocket::timedSend(const string&, const iox::units::Duration&) const -> iox_setsockopt }  :::  [ 9 ]  Bad file descriptor
invalid file descriptor for unix domain socket ""
2022-12-19 15:55:25.527 [Warning]: Process cannot s

Detailed information

E.g. a list of pros and cons of different considerations and how iceoryx and its user could benefit from it

[mossmaurice]

@YeahhhhLi Thanks for opening this issue. Did you have a look at the access control example? There, the setup regarding users and groups is described in detail. Unfortunately, user/groups configuration via the .toml file is not possible at the moment and you need to build a custom RouDi as described in the example. Typically, there is no need to start an app from an iceoryx perspective with root and I also wouldn't recommend to do so for security concerns. Would that be possible in your setup?

[YeahhhhLi]

Thanks for reply

Did you have a look at the access control example? There, the setup regarding users and groups is described in detail.

Yes I did.

However, when we use the cyclonedds shm communication method, the iox service is involved, and we hope that we can meet our needs by modifying the .toml file.

So, is it possible to support the cancellation of shm read and write permissions in the future (of course, it is up to the business side to decide, and the security risk is also borne by the business side)

At the same time, there is another problem. I mentioned this issue before but wrongly mentioned it in the rust repo. (https://github.com/eclipse-iceoryx/iceoryx-rs/issues/67)

Although C++ iox lib is not supported now, is it possible to support it in the future, so that we can start the iox service in our own service initialization phase

[mossmaurice]

@YeahhhhLi

we hope that we can meet our needs by modifying the .toml file.

Turns out I was mistaken. It should be possible to configure the groups with a .toml file. Can you try the following? I used the same values as in the example.

[general]
version = 1

[[segment]]
reader = "unprivileged"
writer = "privileged"

[[segment.mempool]]
size = 128
count = 10000

I'm not aware that someone used this feature before. Maybe some pull requests are needed for fine tuning ;)

If you wanna extend ice_access_control and contribute a .toml which does the same thing as the custom build RouDi, this would be much appreciated :)

So, is it possible to support the cancellation of shm read and write permissions in the future

Everything described in the example is possible to configure. The basic requirement is: Every user needs to be in the iceoryx group, which needs to be configured in your underlying operating system. I think this group might be missing for your root user? Again, running applications as root can easily become a security risk and probably another solution should be preferred.

At the same time, there is another problem. I mentioned this issue before but wrongly mentioned it in the rust repo. (https://github.com/eclipse-iceoryx/iceoryx-rs/issues/67)

Let's take the discussion over to #970 and continue there.

[YeahhhhLi]

I think this group might be missing for your root user?

@mossmaurice Hello. I just tried to associate the user and user group, and then restarted, and found that some permission errors will be reported

Logs printed by self-service:

Log level set to: [Warning]
/root/iceoryx/iceoryx_hoofs/source/posix_wrapper/file_lock.cpp:53 { iox::cxx::expected<iox::posix::FileLockError> iox::posix::FileLock::initializeFileLock() -> iox_open }  :::  [ 13 ]  Permission denied
permission to access file denied "/tmp/iox-unique-roudi.lock"
2022-12-20 12:20:36.228 [ Fatal ]: Error occurred while acquiring file lock named iox-unique-roudi
2022-12-20 12:20:36.229 [ Error ]: ICEORYX error! ICEORYX_ROUDI_MEMORY_MANAGER__COULD_NOT_ACQUIRE_FILE_LOCK

Logs printed by iox-roudi service:

2022-12-20 12:21:28.557 [Warning]: Process cannot send message over communication channel
2022-12-20 12:21:28.558 [Warning]: ICEORYX error! POSH__ROUDI_PROCESS_SEND_VIA_IPC_CHANNEL_FAILED
2022-12-20 12:21:30.127 [Warning]: Application iceoryx_rt_2712_1671510036337922976 not responding (last response 1569 milliseconds ago) --> removing it
/root/iceoryx/iceoryx_hoofs/source/posix_wrapper/unix_domain_socket.cpp:367 { iox::cxx::expected<iox::posix::IpcChannelError> iox::posix::UnixDomainSocket::initalizeSocket() -> iox_connect }  :::  [ 13 ]  Permission denied
permission to create unix domain socket denied "/tmp/iceoryx_rt_2712_1671510036337922976"
/root/iceoryx/iceoryx_hoofs/source/posix_wrapper/unix_domain_socket.cpp:238 { iox::cxx::expected<iox::posix::IpcChannelError> iox::posix::UnixDomainSocket::timedSend(const string&, const iox::units::Duration&) const -> iox_setsockopt }  :::  [ 9 ]  Bad file descriptor
invalid file descriptor for unix domain socket ""

Let me describe our usage scenario again so that you can understand it in detail: 1、Start iox-roudi: my iox toml file:

[general]
version = 1

[[segment]]

[[segment.mempool]]
size = 1088
count = 512

[[segment.mempool]]
size = 16448
count = 1024

[[segment.mempool]]
size = 262208
count = 256

[[segment.mempool]]
size = 1048640
count = 256

[[segment.mempool]]
size = 4194368
count = 256

[[segment.mempool]]
size = 8388672
count = 128

Then I start the service by the following command:

/abs/path/iox-roudi -c aos/transport/cyclone/config/iox_config.toml

2、Start our own service

Opening with sudo is due to some other needs of our service

sudo ./my_services  {argv}

When the two services are started successively, the error at the beginning is reported.

And I found some files about iox in /tmp:

total 4
-rw------- 1 root  root            0 Dec 20 12:19 iceoryx_rt_2459_1671509945237909683.lock
-rw------- 1 root  root            0 Dec 20 12:20 iceoryx_rt_2712_1671510036337922976.lock
-rw------- 1 yeah domain_users    0 Dec 20 12:18 iox-unique-roudi.lock
srw-rw---- 1 yeah domain_users    0 Dec 20 12:19 roudi
-rw------- 1 yeah domain_users    0 Dec 20 12:18 roudi.lock

Is it related to these temporary files?

[mossmaurice]

@YeahhhhLi Thanks for the detailed post!

Which version of iceoryx are you using?

just tried to associate the user and user group, and then restarted, and found that some permission errors will be reported

On some embedded systems permissions changes might not be permanent and will be reset. Could you try again without a restart?

For setting up the shared memory configuration, iceoryx uses sockets to communicate from the application to RouDi and vice-versa during startup. The permissions of the sockets are configured so that every user in the same group can access it as you can see in your output:

srw-rw---- 1 yeah domain_users    0 Dec 20 12:19 roudi

Here, all users in the group domain_users can write to RouDi's socket.

Additionally, every application creates a .lock file, to make sure RouDi and the other applications can only be started once. The lock file of course is only available to the users and not to groups:

-rw------- 1 root  root            0 Dec 20 12:19 iceoryx_rt_2459_1671509945237909683.lock
-rw------- 1 yeah domain_users    0 Dec 20 12:18 roudi.lock

What I can tell from the above logs is that, your my_service application is started as root. Therefore, if you want to keep using the root user you need to adapt the groups in such a way that the socket of RouDi can be accessed. And vice-versa RouDi can access the socket of the application.

Opening with sudo is due to some other needs of our service

Again, I would suggest you to think about lowering the requirement to run your own service as root for security reasons. Could you refactor ./my_services {argv} in such a way that running it as root is not needed?

Is it related to these temporary files?

It's very likely, if the lock files in /tmp where created with the wrong permissions before they will not be removed and re-created. Hence, before any new try you should always delete them with rm -rf /tmp/*.

Summary:

1. rm -rf /tmp/* before starting the apps
2. All users need to be in a common group like in the ice_access_control example.

Hope this helps!

[elBoberido]

@YeahhhhLi can this issue be closed?

[elBoberido]

@YeahhhhLi closing this issue. Feel free to reopen it if you still have questions