Unable to self-reboot when the device has no IP?

[Mads]

I have an RT-application running on a Linux RT target with both netwrok interfaces set to DHCP only (no link local fallback) where the application should:

a) be able to start and run normally even though none of the network connections are up

b) restart the target (itself) in this offline state

Now, the good news is that it seems that requirement a is fulfilled. Even though none of the network interfaces get an IP, the RT application still runs as it should. However, it is not able to restart itself if the network interfaces are in such a state.

I am using the System Configuration API's Restart function. It works fine if one of the network interfaces are up, both if I'm using a session input constant to the reboot function set to localhost, or if I use the init function to get a session. Is this because in either case it will try to point the command to "locahost", and with no network up - the command will fail to connect to localhost?

If that is so, is there a different approach that will work (using the API, or do I need to use system exec perhaps)?

The old RT API had a Restart "Self" command, but that's not available anymore.

[DJaramillo]

Is this because in either case it will try to point the command to "locahost", and with no network up - the command will fail to connect to localhost? 

Yep, you are correct the System Configuration reboot command implementation relies on a connection to localhost. I'm going to file an internal bug report so we can fix this. In the meantime, you can use a system exec VI and call the '/sbin/reboot' command from your application.

[tduffy]

@DJaramillo: Just to be clear, lvuser has enough privilege to reboot the device?  Isn't that a rather significant security vulnerability?  Is there a list somewhere of what lvuser can and can not do?  Thanks for your response on this.

[ScotSalmon]

LabVIEW RT's elevated capabilities are:

CAP_SYS_RAWIO,CAP_NET_BIND_SERVICE,CAP_SYS_BOOT,CAP_SYS_NICE,CAP_IPC_LOCK,CAP_SYS_TIME

Capabilities grant processes privileges which can definitely affect security. See http://man7.org/linux/man-pages/man7/capabilities.7.html for details.

These are listed in the LVRT post-install script, I'm not sure they're documented elsewhere. I'll see about getting a doc created on the community for this information.

[tduffy]

Thanks for the quick response @ScotSalmon!

[Mads]

Is it possible for us to edit the list of capabilities given to the lvuser?

I'm just thinking that if the lvuser had CAP_NET_ADMIN I could resolve the ARP issue described here, by getting access to ip link commands(?)

[ScotSalmon]

See http://linux.die.net/man/8/setcap -- we'll include that the KB or other doc we end up posting on this. Note that currenltly that change would be clobbered if you reinstall LV, though.

[Mads]

DJaramillo - the failure of the System Configuration API to run the reboot command when there is no network....Does that affect other functionality of the API as well, or is the reboot command special in that regard?

Replacing the reboot with the system exec alternative is fine because that's readily available...there are other parts of the API usage that will be more painful to miss out on

[DJaramillo]

Mads wrote:

DJaramillo - the failure of the System Configuration API to run the reboot command when there is no network....Does that affect other functionality of the API as well, or is the reboot command special in that regard?

This affects other areas of the System Configuration API:

• Functionality under the "Software Management" subpalette would be affected
  • Most of this functionality is not supported locally anyway
  • The exception would be "Set Image" which I would expect to work
• Functionality under the "Hardware Management" subpalette should work fine

[Mads]

I first tried using setcap on the rtexecutable file (as adding it to the lvuser user seemed to be more difficult(?)), writing this while in the rtexe directory:

setcap cap_net_admin startup.rtexe

That returns a fatal error, and it says that the filename must be a regular (non-symlink) file...so after some more digging I found out that I needed to write:

setcap cap_net_admin=eip startup.rtexe

That seemed to run fine (if I use getcap it returns that the file has the requested capability), but if the executable tries to run an ip link command it still fails (returns RTNETLINK answers: Operation not permitted). Perhaps cap_net_admin is not enough...or?