Merged sdwdate python branch into master.
Merged.
(But your branch is behind now. Please fetch/merge before making new changes.)
Merged Whonix branch.
Removed usr/share/test_d_files.
Cherry picked sdwdate pool configuration.
About
Conflicts:
usr/lib/sdwdate/modules.d/sdwdate
it was removed early in the development of the python branch.
But in the wrong branch. Let’s move on to the sdwdate master branch.
Please checkout master, merge origin/master, and apply your work on top
of the master branch.
That’s a solution to get sdwdate-gui shown in all environments.
There is a subsequent commit for running sdwdate-gui as sdwdate.
A question about NotShowIn=QUBES. according to freedesktop.org, the string should exist in a variable XDG_CURRENT_DESKTOP. Cannot find it in the environment.
Why do we need etc/xdg/autostart/sdwdate-gui-other.desktop?
Does Exec=kdesudo /usr/bin/sdwdate-gui fail in Non-Qubes-Whonix?
Yes, it pops up a gui asking for the password.
That’s why xhost +local:root was implemented first hand.
How does Qubes prevent this?
And can we implement the same solution in Non-Qubes-Whonix?
As far as I can see, whonix-gw and whonix-ws terminals are passwordless (sudo or kdesudo never prompt for a password). Guessing we would have to implement the same in non Qubes-Whonix.
(https://github.com/Whonix/whonix-setup-wizard/blob/master/etc/sudoers.d/whonix-setup-wizard vs sdwdate-gui/sdwdate-gui at master · troubadoour/sdwdate-gui · GitHub)
I am not sure anymore. Did we suppose to run sdwdate-gui as user sdwdate?
Please try.
kdesudo -u sdwdate /usr/bin/sdwdate-gui
That should work everywhere. Including without password in Non-Qubes-Whonix. I think we can make kdesudo work without password in Non-Qubes-Whonix somehow.
That works everywhere, don’t know what went wrong in my previous tests.
I should re-read myself. In Qubes,
2 - if started as user sdwdate, a d-bus error pops up.
Client failed to connect to the D-BUS daemon:
Failed to connect to socket /tmp/dbus-xxxxxxxxx: Connection refused
We may have run sdwdate-gui as root.
Not so quick. If there is such an issue in Qubes, we should make sure it’s already been reported or at least report before we add the workaround.
@marmarek any idea about this?
Perhaps this issue is similar to this one:
https://phabricator.whonix.org/T424
?
I did find something (forgot to bookmark) about the dbus connection refusal related to starting a program as a different user.
kdesudo -u sdwdate /usr/bin/sdwdate-gui also fails for me in a Qubes Debian VM also.
kdesudo(14366) KDESu::KDESuPrivate::KCookie::getXCookie: No X authentication info set for display ":0"
(process:14375): GConf-WARNING **: Client failed to connect to the D-BUS daemon:
Failed to connect to socket /tmp/dbus-JvqUfOKDDa: Connection refused
So for now this issue isn’t releated to /etc/xdg/autostart. Investigating…
That error happens in Qubes Debian VMs, but not in Non-Qubes-Whonix. I try reproduce with something simpler.
Do you have $DBUS_SESSION_ADDRESS set in that environment?
Doesn’t look like.
env | grep -i DBUS
KONSOLE_DBUS_SERVICE=:1.16
KONSOLE_DBUS_WINDOW=/Windows/1
KONSOLE_DBUS_SESSION=/Sessions/1