Debug container priviledges

Lloyd · June 4, 2026, 10:21am

Hi,

Here is the details to my system:

Software summary
------------------------------------------------------------
Bootloader:               U-Boot
Kernel version:           6.6.119-7.5.0-00057-g86497e203ba0 #1-Torizon SMP PREEMPT Mon Jun 30 14:11:55 UTC 2025
Kernel command line:      root=LABEL=otaroot rootfstype=ext4 quiet logo.nologo vt.global_cursor_default=0 plymouth.ignore-serial-consoles splash fbcon=map:3 ostree=/ostree/boot.0/torizon/7f1184bf220a/0
Distro name:              NAME="Torizon OS Upstream"
Distro version:           VERSION_ID=7.5.0-build.30
Distro variant:           VARIANT="Docker"
Hostname:                 colibri-imx7-emmc-07311078
------------------------------------------------------------

Hardware info
------------------------------------------------------------
HW model:                 Toradex Colibri iMX7D 1GB (eMMC) on Colibri Evaluation Board V3
Toradex version:          0039 V1.1B
Serial number:            07311078
Processor arch:           armv7l
------------------------------------------------------------

I am writing C# code to access the CAN bus and thus control/interrogate the controller in our product. My development environment is VS code with the Torizon extension

The first thing the C# application does is check if it has NET_ADMIN privileges. This is needed to configure the CAN bus. This privilege is granted to the container/application using the docker-compose directive:

    cap_add:
    - NET_ADMIN

and when I build and execute my container the application reports that It has this privilege.

However, when I debug the container the application reports It does not have this privilege and the application aborts.

The debug container definition in the docker-compose.yml file also has the above cap_add statement.

How do I run the application in the debugger with this privileges?

Regards
Lloyd

ToradexAI · June 4, 2026, 10:22am

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.

To address the NET_ADMIN capability issue in your debug container for CAN bus access, you need to ensure that the debug service in your docker-compose.yml file has the correct configuration(1).

Debug Container Configuration

For .NET applications using the Torizon IDE Extension, the debug container service should include the cap_add directive(1). Here’s the correct configuration structure:

gpiodotnet-debug:  
build:  
context: .  
dockerfile: Dockerfile.debug  
image: ${LOCAL_REGISTRY}:5002/gpiodotnet-debug:${TAG}  
ports:  
- ${DEBUG_SSH_PORT}:${DEBUG_SSH_PORT}  
volumes:  
- type: bind  
source: /dev  
target: /dev  
device_cgroup_rules:  
- "c 254:* rmw"

(1)

For your CAN bus application, you should modify the debug service to include:

cap_add:
- NET_ADMIN

Verification Steps

Check your docker-compose.yml structure: Ensure both the debug service (typically named <project>-debug) and the release service have the cap_add: - NET_ADMIN configuration(1).
Rebuild the debug container: After modifying the docker-compose file, rebuild your debug container using the Torizon IDE Extension tasks(1).
Verify the debug container deployment: The debug container is deployed and executed on the target device when debugging applications, and this container is defined by Dockerfile.debug(2).

Additional Considerations

The debug container configuration differs from the release container because it contains additional dependencies and settings to enable remote debugging(2). Make sure your debug service configuration matches the pattern shown in the .NET example documentation, but with the addition of the NET_ADMIN capability for CAN bus access.

If you continue to experience issues, verify that the debug container is properly receiving the capability by checking the container’s capabilities once it’s running on your Colibri iMX7D device.

Best regards, Toradex AI Assistant.

Did you like my answer?

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

Lloyd · June 4, 2026, 10:29am

@ToradexAI

As I stated in my request the docker service for the debug container has the configuration to grant NET_ADMIN privileges.

Both the debug and release containers have this definition.

    cap_add:
    - NET_ADMIN

I have confirmed the application and release container have the correct privileges.

When the application is run in the debugger it does not.
What do I need to change in the debugger scripts to run the application with this privilege?

Regards
Lloyd

ToradexAI · June 4, 2026, 10:29am

I understand your issue better now. The debug container is properly configured with cap_add: - NET_ADMIN in your docker-compose.yml, but the debugger isn’t honoring these capabilities when launching your C# application.

Debug Launch Configuration

The issue likely lies in the VS Code launch configuration. When debugging applications, the Torizon IDE Extension uses specific launch configurations defined in the .vscode/launch.json file(1). These configurations control how the debugger starts your application, and may not be inheriting the container capabilities properly.

Debugging Process Flow

When you start a debugging session, the IDE extension triggers several tasks that build and run the container application with configurations that enable remote debugging via SSH(1). The debug container is deployed and executed on the target device when debugging applications, and this container is defined by Dockerfile.debug(2).

Troubleshooting Steps

Verify the debug container is using docker-compose: Ensure that the debugging process is actually using your docker-compose.yml file with the NET_ADMIN capability. The debug container should be launched using the docker-compose configuration, not just the raw Docker image.
Check the launch.json configuration: Review your .vscode/launch.json file to ensure it’s properly configured for your .NET application(3). This file is used to store the configurations to launch the application with the debugger(3).
Verify task dependencies: The debugging process relies on a chain of tasks defined in tasks.json(3). These tasks are used by the launch.json in a dependency chain to build and deploy the application on the target before the launch of the debugger(3).

Alternative Approach

If the issue persists, you might need to modify how the debugger launches your application. Since the debug container contains only a copy of the build directory and build files are copied to the debug container through SSH(2), the container capabilities should be preserved if the docker-compose service is properly configured.

You may find relevant discussions on the Toradex Community by searching for “debug container capabilities” or “NET_ADMIN debugging”.

Best regards, Toradex AI Assistant.

Did you like my answer?

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

jeremias.tx · June 4, 2026, 6:25pm

Greetings @Lloyd,

Not sure why you’re seeing this behavior on the debug container, but I have some theories. It might be due to the difference in how the application is packaged between the release and debug containers.

In the release container the application binary is packaged directly into the container image: vscode-torizon-templates/dotnetConsole/Dockerfile at dev · torizon/vscode-torizon-templates · GitHub

While in the debug container the application binary is not part of the container image. It gets copied to the running debug container over network during the debug process: vscode-torizon-templates/dotnetConsole/.vscode/tasks.json at dev · torizon/vscode-torizon-templates · GitHub

Perhaps this difference is what is causing your privilege detecting logic to fail. Not saying this is the cause, but it is a difference between the two configurations.

Another idea. So, you said your application has logic to check the privileges in the container. Maybe the logic is giving a false negative. If you run a test and do something in the debug container that would require NET_ADMIN privilege to work, does it succeed or fail?

It could be the case that the privilege checking logic is wrong and NET_ADMIN is actually enabled.

In fact just as a test I created a default dotnet console project using our extension. I added NET_ADMIN to the debug part of the compose file and ran the debug process. On the device while the debug container was running I used docker exec to get a shell into the container itself and installed capsh to check the available capabilities in the container.

From this test I can see that the NET_ADMIN capability is enabled in the debug container:

root@c97c9032b1f4:/# capsh --print | grep "Current:"
Current: cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_admin,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap=ep

This could be further indication that the issue might be the privilege checking logic in the application.

Best Regards,
Jeremias

Lloyd · June 12, 2026, 7:54am

Hi @jeremias.tx

The ‘privilege checking logic’ is in a C# application, which attempts to change the CAN bus interface configuration using a dllImport of libc’s setsocket() function. Specifically the bit rate.

It is that code which is reporting that it does not have enough privileges when run in a debugging container.

This code reports OK when run from a release container with NET_ADMIN and changes the bit rate correctly. But reports insufficient privileges when run from a debug container which also has NET_ADMIN privileges.

I believe both containers are granted the same privileges when the container is created.
For the release container:

Current: cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_admin,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap=ep

and the command Whoami reports root.

For the debug container:
Current: cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_admin,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap=ep
and the command “whoami” reports root.

I am investigating if it has to do with the priviledges of the account, used by the debugger, which started the application.

Lloyd

jeremias.tx · June 12, 2026, 3:58pm

I am investigating if it has to do with the privileges of the account, used by the debugger, which started the application.

That’s another good idea to investigate. I believe the user that executes the debug process is not the same as the user that executes in the debug case. At least you were able to confirm that the issue is not with the privileges the container itself has.

Best Regards,
Jeremias

Lloyd · June 15, 2026, 11:31am

Hi @jeremias.tx

So if you:

torizon@colibri-imx7-emmc-07311078:~$ docker exec torizon-caninterface-debug-1 ps aux

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.1  0.6  10516  6344 ?        Ss   11:24   0:00 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups
root        24  0.1  0.6  10888  6720 ?        Ss   11:24   0:00 sshd: torizon [priv]
torizon     30  0.1  0.4  11148  4852 ?        S    11:24   0:00 sshd: torizon@notty
torizon     31  0.0  0.0   1612   996 ?        Ss   11:24   0:00 sh -c /vsdbg/vsdbg --interpreter=vscode
torizon     32 22.3 13.8 424580 140720 ?       Sl   11:24   0:26 /vsdbg/vsdbg --interpreter=vscode
torizon     43  5.1  7.9 557880 80612 ?        Sl   11:24   0:06 /home/torizon/app/caninterface
root        70 69.2  0.3   6496  3460 ?        Rs   11:26   0:00 ps aux

Is there a way to change the user from torizon to root in the scripts or settings?

Lloyd

jeremias.tx · June 15, 2026, 4:22pm

Is there a way to change the user from torizon to root in the scripts or settings?

The default debug configuration uses the user set by torizon_run_as: vscode-torizon-templates/dotnetConsole/.vscode/launch.json at dev · torizon/vscode-torizon-templates · GitHub

I believe this setting is found in your project’s settings.json file.

Best Regards,
Jeremias

Lloyd · June 16, 2026, 9:25am

Hi @jeremias.tx

That does work but only if you change the user in the ssh-check script.

        {
            "label": "ssh-check",
            "detail": "",
            "hide": true,
            "command": "xonsh",
            "type": "shell",
            "args": [
                "${workspaceFolder}/.conf/service-check.xsh",
                "ssh",
                "${config:torizon_psswd}",
                "${config:torizon_debug_ssh_port}",
--->            "${config:torizon_run_as}",
                "${config:torizon_ip}",
                "echo ssh-ok"
            ],
            "dependsOrder": "sequence",
            "problemMatcher": "$tsc",
            "icon": {
                "id": "repo-pull",
                "color": "terminal.ansiYellow"
            },
            "presentation": {
                "echo": true,
                "reveal": "always",
                "focus": true,
                "panel": "shared",
                "group": "build-execution"
            }
        },

If you don’t change this user from torizon_login then the ssh-check fails 15 times and then aborts, which prevents the torizon_run_as feature from working.

Regards
Lloyd

jeremias.tx · June 16, 2026, 3:55pm

With the changes does the privileges now work as you would like in the debug configuration?

Best Regards,
Jeremias

Lloyd · June 16, 2026, 6:47pm

@jeremias.tx
Yes, the debug container now runs the application with the root account similar to the release container. This allows the app to have the correct privileges to access the CAN interface and make changes such as baud, and loopback etc.

jeremias.tx · June 16, 2026, 8:09pm

Perfect, glad we were able to resolve this.

Best Regards,
Jeremias

Lloyd · June 17, 2026, 7:40am

@jeremias.tx This is a change to the script, is there a chance that the script can be reset when a new release is made and I need to make the change again?

If this is so I will create a delta blog on our confluence site to remind me.

Lloyd

jeremias.tx · June 17, 2026, 3:58pm

This is a change to the script, is there a chance that the script can be reset when a new release is made and I need to make the change again?

Normally if there is a change to the default project template, it shouldn’t automatically change your pre-existing projects. Unless you explicitly run the try-update-template task.

That said, I don’t know if I can guarantee this for ever case in the future. I would recommend that you note this down either way just in case.

Best Regards,
Jeremias