CAN Setup on EDGAR fails due to insufficient permissions

[hafklin]

When an EDGAR instance is instructed to use a CAN interface by a ClusterAssignment, the logic for configuring CAN on the peer executes several shell commands to create the vcan interface and set up the required cangw rules. These commands, however, require elevated privileges, which causes them to fail when EDGAR is deployed outside of the test environment. For the logic to set up Ethernet interfaces, this appears to be solved by granting the EDGAR executable the CAP_NET_ADMIN capability. However, the shell commands for CAN setup being executed in a different process causes this to fail here.

I made some first attempts to fix this, but it seems that it cannot be solved by simply making the CAP_NET_ADMIN capability for the EDGAR executable inheritable. Perhaps Ambient capabilities are a solution here?

[mbfm]

Our strategy so far has been to avoid modifying the system interfaces with external commands, so that we only need CAP_NET_ADMIN on EDGAR's executable.

However, it probably won't be the last time that we'd like to use some external command here, so we're certainly open to using a more flexible approach, with e.g. ambient capabilities.

For simplicity, we're currently using the File Capabilities, which don't have ambient capabilities listed in this page, but I'm honestly not sure, if there really is a conceptual difference between File Capabilities and User Capabilities. As I understand, the User Capabilities are themselves set by assigning the respective File Capabilities to the PAM module.

Potentially, we might need a separate service user for EDGAR, though. We had code for this beforehand, which got removed in this commit: https://github.com/eclipse-opendut/opendut/commit/967540711bbdd33c821b49e7354b33df73b61eb6