Connman: user rights

As part of you security update for our embedded device, we changed the running service user (systemd) from root to a new created user “codatex” and added it to the groups video, input, plugdev and netdev (also tried systemd-network). We changed the user rights on the necessary folders and files. Finally, we added a udev rule to change the permissions / ownership of ttymxc[1-2], as they are assigned to root by default. After all, we still get some connman related errors:

May 19 16:36:59 colibri-imx6 bash[248]: "Rejected send message, 2 matched rules; type="method_call", sender=":1.5" (uid=1000 pid=256 comm="/home/codatex/ZE16Terminal ") interface="net.connman.Manager" member="GetProperties" error name="(unset)" requested_reply="0" destination="net.connman" (uid=0 pid=291 comm="/usr/sbin/connmand -n ")"
May 19 16:36:59 colibri-imx6 bash[248]: "Rejected send message, 2 matched rules; type="method_call", sender=":1.5" (uid=1000 pid=256 comm="/home/codatex/ZE16Terminal ") interface="net.connman.Manager" member="GetServices" error name="(unset)" requested_reply="0" destination="net.connman" (uid=0 pid=291 comm="/usr/sbin/connmand -n ")"

For most parts, we use the build-in network API of Qt. For some special cases (which are not covered by Qt), we directly call connmanctl. The real fun part: We get this errors during the application start and at this point, where are not calling connman directly (but some Qt network stuff).

Also, all calls over network API provided by Qt seem to work, however direct calls of connman are obviously not working…

Any idea how to fix this issues? Did we missed a group? Would switching to systemd-network be an option? (as it is already installed by default). We use Ethernet, WiFi or Cellular Data (the last two are realized with USB dongles).

Hi

While we don’t have experience with the route you take.

I believe that dbus does reject the message even before delivering it to connmand rather than connmand rejecting it.

I assume that the following file is a good starting point to address the issue:

Max

Thanks, you are right, the dbus policy was only configured for root.