[SDK] Run SDK without sudo rights or setcap

[MaximilienNaveau]

The fact of running the connection through a protected socket is problematic as we need sudo rights to run the low level controllers on the robot.

I would like to start here a brainstorming on how to fix it.
I am ready to invest time to fix this issue.

[thomasfla]

Hi @MaximilienNaveau I agree that having to run controllers as root is not very nice.

Brainstorming here is a good idea,

I think the proper way to do things is to write a Linux driver in kernel land, but I'm far from being an expert on this topic. I did look at it quickly when writing the first version of the MB SDK but quickly gave up.

[MaximilienNaveau]

I think the proper way to do things is to write a Linux driver in kernel land

I do not know what that means I will read on this.

I also considered a ip-table mapping the internet port to a none protected one.

pros:

• you only need sudo to put the port forwarding in place once
• all users can use the same port to communicate with the robot without sudo.

cons:

• additional time delay introduced. (I think it could still be an efficient way to do this)

[thomasfla]

Unfortunately we are not using the TCP/IP protocol so there is no notion of Port or IP table. We are working at MAC layer.

The reason for not using TCP/IP but only raw socket, was motivated by the real time wifi connection needs.

If we decide to use IP (with UDP packets for example), we will need to drop realtime wifi feature, and also spend quite some time on the MB firmware again. Also we need to benchmark the latency.

[jviereck]

So it looks like we want to use raw sockets for speed and because we have settled on them in the past. In this case we need to run an executable as root.

I wonder if we could write a small "odri_relay" executable. This one runs with sudo privileges and has the raw socket open. It then exposes the data from and to the raw socket via a UDP connection on a local port. When launching the master board SDK software, instead of connecting to the robot directly, one will connect to the relay station / executable. My hope is that using UDP on localhost doesn't create too much of a latency overhead.

I also though about using shared memory. However, I think shared memory has the same access privileges as the program creating the shared memory object. That means, if the executable needs to run as sudo, then all processes reading and writing to the shared memory will have to run as sudo as well. So this won't solve the problem we are facing now.

In addition, this executeable could pop-open a basic gui to give insight about the traffic quality, raw readings etc to monitor the communication.

What do you think?

[nim65s]

I think the proper way to drive hardware from linux with elevated privileges is to write a kernel module, and package it with DKMS.

I already started to work on that a long time ago, but it was aborted after some discussions with @thomasfla, and I can't remember why.

@jviereck : your solution would also work, and be easier to implement. But I don't understand why you want to add UDP : I think we could just use a named fifo, which would remove the need for a transport layer.

[jviereck]

I just didn't knew about named fifos... Looks indeed simpler than UDP! However, if you launch the process as root and create a named fifo, can other processes with less privileges access it? Just checking.

On June 13, 2021 4:50:07 AM EDT, Guilhem Saurel ***@***.***> wrote: I think the proper way to drive hardware from linux with elevated privileges is to write a kernel module, and package it with DKMS. I already started to work on that a long time ago, but it was aborted after some discussions with @thomasfla, and I can't remember why.

***@***.*** : your solution would also work, and be easier to implement.

…

But I don't understand why you want to add UDP : I think we could just use a named fifo, which would remove the need for a transport layer. -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #84 (comment)

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

[wxmerkt]

I think the proper way to drive hardware from linux with elevated privileges is to write a kernel module, and package it with DKMS.

Not quite - the trick here is called setcap to set permissions on the executable to work directly on the raw sockets. This requires sudo to set the capabilities but it will not require sudo during runtime. You will have to run setcap after every compilation. Note, setcap does not work on ecryptfs encrypted home directories.

[nim65s]

@jviereck : the fifo will just be a special file on the file system, and other processes will be able to write to it if they have the permission for this. So I guess we would want it to have a meaningful owner group, with permissions g+w, and add the authorized users in that group. Or, just simply put it a+w.

@wxmerkt : I think you misread the title of the issue ;)

edit: there was an old habit to put fifos in /tmp, but this is no longer the best idea since linux 4.19: https://unix.stackexchange.com/a/503169

[wxmerkt]

@wxmerkt : I think you misread the title of the issue ;)

You're right, apologies! I'll hide the previous comment

[jviereck]

I think @wxmerkt comment was super helpful! What I would like to do is enable the user to run the robot setup completely without sudo rights.

What we should be able to do is this:

$ make odri_relay
$ sudo setcap cap_net_admin,cap_net_raw+ep odri_relay

Then as the user:

$ odri_relay enp5s0f1 ~/odri_relay.fifo
$ ./your_blmc_program ~/odri_relay.fifo

Because the odri_relay is not depending on anything in the LD_LIBRARY_PATH, this should work.

What do you think?

[MaximilienNaveau]

I am also in favor for a solution here,
I would think that a properly packaged kernel module with DKMS would be simpler in the long run though.
The reason is that there is less operations needed from the user to actually use the robot.
Just an installation phase if I understand it properly.
This will prevent people to do some mistakes.
But I guess this will be more work for us @nim65s ?
But that is just my 2 cents on the matter.

I am willing to spend time on this as this is particularly annoying...

[jviereck]

I am willing to spend time on this as this is particularly annoying...

Awesome! Thank you so much @MaximilienNaveau :)

Let me know if you need any help with this or want me to test/look at some code.