MycroftAI / mycroft-core

Mycroft Core, the Mycroft Artificial Intelligence platform.
https://mycroft.ai
Apache License 2.0
6.52k stars 1.27k forks source link

Deb Package Install Breaks Desktop Environment related Skills #583

Closed AIIX closed 4 years ago

AIIX commented 7 years ago

Testing Platform Version: Mycroft-Core DEB Package on KDE Neon 16.10.

Description of the Issue:

Plasma Desktop Skills such as Krunner, Activities, Internal System Functions such as Lock Screen, Switch Users, Logout communicate with Mycroft Skills over session DBUS. Mycroft-Core Deb Package runs Mycroft under a separate user "Mycroft" and Group "Mycroft" this breaks down communication with Dbus as all the Dbus Interfaces are expecting logged in user's UID on method-calls but instead method-calls are generated by user "Mycroft" UID. The workaround to this issue is os.setuid() provided by "import os" but is not a solution as this requires Root access on every call and running a skill as Root seems like a bad idea. This bug not only affects the current available desktop integration skills but i believe will affect even future desktop deployments especially where system internals do not expose python bindings for accessing their functions and the dev has to depend on already available Dbus interfaces as a viable communication channel.

Sample Error Running as User "Mycroft": Traceback (most recent call last): File "/usr/local/lib/python2.7/site-packages/mycroft_core-1489623931-py2.7.egg/mycroft/skills/core.py", line 245, in receive_handler handler(message) File "/opt/mycroft/skills/mycroft-internals-plasma-skill/init.py", line 54, in handle_internals_lock_plasma_skill_intent remote_object = bus.get_object("org.kde.ksmserver","/ScreenSaver") File "/usr/lib/python2.7/dist-packages/dbus/bus.py", line 241, in get_object follow_name_owner_changes=follow_name_owner_changes) File "/usr/lib/python2.7/dist-packages/dbus/proxies.py", line 248, in init self._named_service = conn.activate_name_owner(bus_name) File "/usr/lib/python2.7/dist-packages/dbus/bus.py", line 180, in activate_name_owner self.start_service_by_name(bus_name) File "/usr/lib/python2.7/dist-packages/dbus/bus.py", line 278, in start_service_by_name 'su', (bus_name, flags))) File "/usr/lib/python2.7/dist-packages/dbus/connection.py", line 651, in call_blocking message, timeout) DBusException: org.freedesktop.DBus.Error.ServiceUnknown: The name org.kde.ksmserver was not provided by any .service files

aatchison commented 7 years ago

Thanks for fleshing this out some more. I'll try to catch up with you soon to see if we can't fix these packaging issues.

ghost commented 7 years ago

Would a solution be to modify the mycroft-core packaging to disable the automatic system service? This would then allow the plasmoid to start mycroft itself as the local user?

AIIX commented 7 years ago

@clifforD I have already tried that method but it still runs under the user mycroft as defined in the Service files..only on changing Runas: might be useful there but use case scenario how to guess logged in user who has access to Dbus.. Not everyone is running at uid 1000.. That might be an issue in itself. On modifying the runtime and scripts to run as current user you end up with logs asking to run the install_mimic.sh this causes voice client to break.. Additionally sorry for closing the issue it seems like my android git hub app keeps crashing on submit and post. The issue is still open.. on the solution side i believe it should be the mycroft skills running from the users own UID rather than user "Mycroft" you might have voice and messagebus running of "mycroft" user.. but skills should have access to local users activities and dbus connections.

AIIX commented 7 years ago

Additionally to the above this is another error I have found.. message bus does not connect when trying to run systemctl mycroft-* any as a local user specified by the tag --user without having to run sudo.

krisgesling commented 4 years ago

Hey @AIIX, is this still relevant or can we close it up?

AIIX commented 4 years ago

Not sure if the deb package is still an official method for installation from 2017, but guess its ok to close this.