The org.trinitydesktop.hardwarecontrol service is not accessible by the user anymore #12

Basic information

TDE version: 14.1.0
Distribution: Debian Stretch
Hardware: amd64

Description

Since the upgrade at latest 14.1 the org.trinitydesktop.hardwarecontrol service is not accessible by the user anymore. I am pretty sure it worked before as we discussed the availability of the Introspectable interface and I tested it.

$ dbus-send --print-reply --system --dest=org.trinitydesktop.hardwarecontrol /org/trinitydesktop/hardwarecontrol org.freedesktop.DBus.Introspectable.Introspect
Error org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 2 matched rules; type="method_call", sender=":1.50" (uid=1000 pid=7200 comm="dbus-send --print-reply --system --dest=org.trinit") interface="org.freedesktop.DBus.Introspectable" member="Introspect" error name="(unset)" requested_reply="0" destination="org.trinitydesktop.hardwarecontrol" (uid=0 pid=4172 comm="/opt/trinity/bin/tde_dbus_hardwarecontrol ")

From the root account it is possible.

Steps to reproduce

normal user does not work
root user works

Hi Emanoil,
have you tried from a remote console? or from a "su" Konsole? This can be the difference. I have been looking into this recently for other reasons and the current behavious should be as follow:

as root, you can access TDE HW DBus daemon from everywhere
as normal user, if you are logged in the actual machine (GUI or console at machine == no remote connection, no "su" within another user session), you should be able to access the TDE HW DBus daemon
as normal user, if you are logged remotely or in a "su" session, then you should have no access to TDE HW DBus daemon.

This is correct behavior but it is also something I intend to work on in relation to some other PR for the suspend code. Currently in Slackware, a normal user can't freeze the system even if kernel support that.

Could you confirm what you see if the same behavior described above?

Correction to previous comment. Behavior for root or local user is the same. In summary, if the person is physically at the machine, he can have access to TDE HW DBus daemon. If not (remote connection or "su -" session), it does not.

(thanks Slavek for spotting this 👍 )

I tested it on a test machine with TDE R14.0.6~pre and everything works as it should. A regular user on a local console, as well as a root on a local text console, gets the expected output. A user connected remotely or switched by su is rejected – access denied.

Note: On the test machine is installed systemd and consolekit is not installed.

Hi,
I am reporting while on the same machine (at_console) as regular user (no su - , or similar).

I do have systemd installed but init is sysv. I did not have ConsoleKit installed after or before the upgrade to latest 14.1.
In a virtual machine with systemd as init and no ConsoleKit installed it is working as expected.
I have on both machines policykit (not sure if it matters).

Obviously something happened while removing tde and installing the new one.

Thanks in advance

If you do not have systemd as an init daemon, then you probably need consolekit. The policykit for tdehw daemon is not used for now - it is yet planned.

It resolved by itself mysteriously. I still do not have ConsoleKit installed

$ dpkg -l | grep -i console
ii  console-setup                           1.164                                       all          console font and keymap setup program
ii  console-setup-linux                     1.164                                       all          Linux specific part of console-setup
ii  gftp                                    2.0.19-5                                    all          X/GTK+ and console FTP client (metapackage)
ii  kbd                                     2.0.3-2+b1                                  amd64        Linux console font and keytable utilities

I tried also a shorter version of the configuration file. I think it is more compact.
Let me know what you think

<?xml version="1.0" encoding="UTF-8"?> <!-- -*- XML -*- -->

<!DOCTYPE busconfig PUBLIC
 "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
 "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>
  <!-- Only root can own the service -->
  <policy user="root">
    <allow own="org.trinitydesktop.hardwarecontrol"/>
  </policy>

  <policy at_console="true">
  <!-- Users with physical access to the machine are allowed access -->
    <allow send_destination="org.trinitydesktop.hardwarecontrol"/>

    <allow send_path="/org/trinitydesktop/hardwarecontrol"
           send_interface="org.freedesktop.DBus.Introspectable"/>
    <allow send_path="/org/trinitydesktop/hardwarecontrol"
           send_interface="org.freedesktop.DBus.Properties"/>
    <allow send_path="/org/trinitydesktop/hardwarecontrol"
           send_interface="org.trinitydesktop.hardwarecontrol"/>
    <allow send_path="/org/trinitydesktop/hardwarecontrol"
           send_interface="org.trinitydesktop.hardwarecontrol.Brightness"/>
    <allow send_path="/org/trinitydesktop/hardwarecontrol"
           send_interface="org.trinitydesktop.hardwarecontrol.CPUGovernor"/>
    <allow send_path="/org/trinitydesktop/hardwarecontrol"
           send_interface="org.trinitydesktop.hardwarecontrol.InputEvents"/>
    <allow send_path="/org/trinitydesktop/hardwarecontrol"
           send_interface="org.trinitydesktop.hardwarecontrol.Power"/>
  </policy>

  <policy context="default">
    <!-- Everyone else is denied access -->
    <deny own="org.trinitydesktop.hardwarecontrol"/>
    <deny send_destination="org.trinitydesktop.hardwarecontrol"/>
  </policy>

</busconfig>

It resolved by itself mysteriously. I still do not have ConsoleKit installed ``` $ dpkg -l | grep -i console ii console-setup 1.164 all console font and keymap setup program ii console-setup-linux 1.164 all Linux specific part of console-setup ii gftp 2.0.19-5 all X/GTK+ and console FTP client (metapackage) ii kbd 2.0.3-2+b1 amd64 Linux console font and keytable utilities ``` I tried also a shorter version of the configuration file. I think it is more compact. Let me know what you think ``` <?xml version="1.0" encoding="UTF-8"?>  <!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN" "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd"> <busconfig>  <policy user="root"> <allow own="org.trinitydesktop.hardwarecontrol"/> </policy> <policy at_console="true">  <allow send_destination="org.trinitydesktop.hardwarecontrol"/> <allow send_path="/org/trinitydesktop/hardwarecontrol" send_interface="org.freedesktop.DBus.Introspectable"/> <allow send_path="/org/trinitydesktop/hardwarecontrol" send_interface="org.freedesktop.DBus.Properties"/> <allow send_path="/org/trinitydesktop/hardwarecontrol" send_interface="org.trinitydesktop.hardwarecontrol"/> <allow send_path="/org/trinitydesktop/hardwarecontrol" send_interface="org.trinitydesktop.hardwarecontrol.Brightness"/> <allow send_path="/org/trinitydesktop/hardwarecontrol" send_interface="org.trinitydesktop.hardwarecontrol.CPUGovernor"/> <allow send_path="/org/trinitydesktop/hardwarecontrol" send_interface="org.trinitydesktop.hardwarecontrol.InputEvents"/> <allow send_path="/org/trinitydesktop/hardwarecontrol" send_interface="org.trinitydesktop.hardwarecontrol.Power"/> </policy> <policy context="default">  <deny own="org.trinitydesktop.hardwarecontrol"/> <deny send_destination="org.trinitydesktop.hardwarecontrol"/> </policy> </busconfig> ```

I intend to work on adding support for authorization through polkit, so config file will probably change at that time.

Does your version above still allow access to the various properties? I see that section is gone, but I have not yet tried it out to be honest.

The answer is simple. There is no destination org.trinitydesktop.hardwarecontrol.Brightness or similar

So send_destination="org.trinitydesktop.hardwarecontrol.Brightness" will never work.

As for the properties it is not clear what exactly is expected for the function to return. Looking in the code is hard to understand why it is there.

In both cases GetAll method returns empty array

dbus-send --print-reply --system --dest=org.trinitydesktop.hardwarecontrol /org/trinitydesktop/hardwarecontrol org.freedesktop.DBus.Properties.GetAll
method return time=1546098763.647026 sender=:1.27 -> destination=:1.43 serial=27 reply_serial=2
   array [
   ]

I intend to rewrite the tde_dbus_hardwarecontrol daemon to use interfaces generated out of the Introspectable returned at the moment. This should make everything more clear and simple.

What I am missing is the call back I see in the call, but not in the output from Introspect call.

If you accept or reject the dbus system.d configuration I would close this issue.

regards

Please do not close this. As said I am working on adding polkit support to tde hw dbus daemon, so after that we will need to test and make sure it works as intended. We can close the issue once this is completed, there is no harm in leave it open a bit longer 😄

In PR #2 the configuration file has been update and the unnecessary Properties entries removed.

I am still using 'send_destination' instead of 'send_path' because it clearly specify the destination and also because it seems all other services are doing so.

to MicheleC & SlavekB!

good day!

I apologize for this, that I am writing here (I have not found how to write a message in PM)
I have some experience in building TDE on Slackware

Link to builds and problems, I hope this will help you and the community

thanks

...

TDE-14.0.6 on Slackware-14.2

vbox images here:

https://sourceforge.net/projects/tde-slackware/files/TDE-14.0.6_SL14.2/VirtualBox/

trouble here:

https://sourceforge.net/projects/tde-slackware/files/TDE-14.0.6_SL14.2/patch/

p.s.

I'm not a hacker, not an expert, so please get up the "error ticket" yourself if you see fit

Thanks Subjob. Yes, problem with shutdown option as normal user is known. I have done some work on that (available on PRs mentioned above) but I have to find the time to clean up some issues before merging to master code.