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

Open
opened 8 months ago by deloptes · 13 comments

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

  1. normal user does not work
  2. root user works
<!-- This is a comment. Please fill in the required fields below. The comments provide instructions on how to do so. Note: You do not need to remove comments. --> ## 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 1. normal user does not work 2. root user works
MicheleC commented 7 months ago
Owner

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?

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?
MicheleC commented 7 months ago
Owner

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 :+1: )

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 :+1: )
SlavekB commented 7 months ago
Owner

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.

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.
deloptes commented 7 months ago
Poster

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

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
SlavekB commented 7 months ago
Owner

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.

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.
deloptes commented 7 months ago
Poster

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"?> <!-- -*- 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> ```
MicheleC commented 7 months ago
Owner

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.

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.
deloptes commented 7 months ago
Poster

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.

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.
deloptes commented 7 months ago
Poster

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

regards

If you accept or reject the dbus system.d configuration I would close this issue. regards
MicheleC commented 7 months ago
Owner

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 :smile:

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 :smile:
MicheleC commented 6 months ago
Owner

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.

In PR #2 the configuration file has been update and the unnecessary Properties entries removed.<br> 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.
sunjob commented 1 month ago

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

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
MicheleC commented 1 month ago
Owner

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.

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.
Sign in to join this conversation.
No Milestone
No Assignees
4 Participants
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
Cancel
Save
There is no content yet.