Documentation on suspending and resuming isn't clear

Technical Support
, , ,
1

This documentation:

States, “Since running containers with root (privileged) permissions isn’t in best practices, these tasks can be performed without root permissions inside a container.”

This is extremely confusing, since the given dbus commands require either sudo or for the container to be run as the root user. While the commands can be run in a non-privileged container, they do still require root.

This thread is also related:

I have no technical issue as my implementation is working correctly now that the user in my container has been given sudo permissions. Please update the documentation to be more clear so others don’t spend as much time as I did. The containers do need to be run as root, but do not need to be privileged.

Dbus permission in a torizon container
2

Hi, I’m the Toradex AI Assistant.

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

I understand your confusion about the suspend/resume documentation. You’re correct that the wording could be clearer. Let me clarify what the documentation means and the different approaches available.

Current Documentation Context

The documentation states that suspend/resume tasks “can be performed without root permissions inside a container” by using bind mounts for required files(1). However, this statement can be misleading because while the container itself doesn’t need to run in privileged mode, the operations still require elevated permissions.

Available Approaches

1. Bind Mount Approach (sysrq-trigger)

The documentation shows using /proc/sysrq-trigger which requires root access but can work in a non-privileged container:

docker run -it --rm -v /proc/sysrq-trigger:/procw/sysrq-trigger torizon/debian:4
echo "b" > /procw/sysrq-trigger

(1)

2. D-Bus Approach

The D-Bus method requires system-level permissions:

docker run -it --rm -v /var/run/dbus:/var/run/dbus torizon/debian:4
apt update && apt-get install -y dbus
dbus-send --system --print-reply --dest=org.freedesktop.login1 /org/freedesktop/login1 "org.freedesktop.login1.Manager.Reboot" boolean:true

(1)

Key Clarifications

The documentation mentions that “reboot via D-Bus is a more proper way to do it, since it will gently ask all daemons and containers to stop before reboot, while sysrq will not do that”(1). However, both approaches require elevated permissions - the difference is:

  • Non-privileged container: The container doesn’t run with --privileged flag
  • Root permissions: The user inside the container still needs root access for system operations

Security Perspective

The documentation acknowledges the security implications: “From a security perspective, bind mounting /proc/sysrq-trigger, which allows performing some low-level commands, or /var/run/dbus, which provides access to system services, may potentially pose a vulnerability”(1).

Recommendation

Your implementation approach is correct - running containers as root user (or with sudo permissions) while avoiding the --privileged flag provides the necessary permissions for system operations while maintaining better security boundaries than fully privileged containers.

The documentation could indeed benefit from clearer language distinguishing between “privileged containers” (using --privileged flag) and “containers running as root user” to avoid the confusion you encountered.

Best regards, Toradex AI Assistant.

Did you like my answer? :+1: :-1:

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

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

3

Greetings @jbernhardt,

Thank you for your feedback, I’ll pass this to our documentation team to consider and revise the documentation.

Best Regards,
Jeremias

1 Like