Dbus permission in a torizon container

Hi all,

In a container (Pyside2+QML) built with VSCode for torizon-core-docker-colibri-imx8x-Tezi_5.7.0+build.17.tar I tried to halt/reboot the host thru dbus as directed in the best practice torizon best practices but I have a permission problem (only with user: torizon, root is ok):

torizon@3cbd30b966fc:/$ dbus-send --system --print-reply --dest=org.freedesktop.login1 /org/freedesktop/login1 "org.freedesktop.login1.Manager.Reboot" boolean:true
Error org.freedesktop.DBus.Error.AccessDenied: Permission denied

From the torizon best practices document, it seems that

these tasks can be performed without root permissions inside a container

The main content of my config.yaml is:

extraparms:
    common:
        mounts: '[{ type: "bind", source: "/dev", target: "/dev", propagation: "shared"
            }, {type: "bind", source: "/var/run/dbus", target: "/var/run/dbus", propagation:
            "shared"}]'
        privileged: 'true'

...

props:
    common:
        appargs: ''
        appname: CarrotGui
        arg: ''
        command: ''
        env: ''
        expose: ''
        extrapackages: dbus python3-dbus
        language: python
        main: main.py
        preinstallcommands: COPY carrot-0.3.0-py3-none-any.whl /carrot-0.3.0-py3-none-any.whl
        runtime: python3
        sdkpostinstallcommands: ''
        sdkpreinstallcommands: ''
        targetcommands: ''
        targetfiles: ''

I turned on the privileged mode because the user must be able to plug and play some USB sensors.

How can I solve the problem? What steps am I missing? I tried to put a configuration file in /etc/dbus-1/system.d with policy but I was unable to fix the problem.

Thank you.
Giulio

Hi @gipo ,

I believe the article meant that these tasks can be performed without running the container in privileged mode (i.e. with option --privileged). The commands themselves should be executed as root, even inside a container.

I will confirm internally if this is really the case, and if it is, the text will be altered to avoid confusion.

Best regards,
Lucas Akira

Hi @gipo ,

I can confirm that the article indeed means “without root permissions” as “without privileged mode”, and you would still need to run commands as root if necessary.

The specific section you referred will be rewritten to better reflect this. Thanks for your question!

Would running the commands as root be a suitable alternative for you?

Best regards,
Lucas Akira

Hi @lucas_a.tx, thank you very much for your reply.

I am trying a workaround from the user @ Juzujka at Shutting down the the Apalis SoM from inside a docker container - #4 by Juzujka but I can’t halt the system anyway because the user must be root.

I changed the sudoers of the customized torizon distro to allow the shutdown for the torizon user but it does not work…

torizon ALL=NOPASSWD:/usr/sbin/shutdown -h now

I am still looking around… about how I can halt the system without writing for root / torizon password…

Best regards, Giulio

Hi @lucas_a.tx,

I managed to shutdown from the container without password by using the scripts mentioned above, running with the user root but creating the shared file inside /var/run/shutdown_signal as torizon user:

sudo -u torizon sh -c 'echo "waiting" > /var/run/my_dir/shutdown_signal'

thus I can write over it from inside the container.

Thank you.
Giulio

Glad you were able to solve this! We appreciate the description of your solution.

Best regards,
Lucas Akira

This article is still extremely confusing.

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

Please update the article to be explicit about what “without root permissions” means in this context, because it does need root permissions.

Hi @jbernhardt,

Could you please open a new thread with your exact question, and use-case of what you are trying to do. This thread is quite old and the article that was referenced in this thread is very different now compared to how it was when this thread was originally created. So it would be best to just open a new thread so we can have a fresh discussion with you regarding whatever questions you may have.

Best Regards,
Jeremias

Done.