Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Does not work on Arch Linux #32

Open
ghost opened this issue Feb 18, 2019 · 4 comments
Open

Does not work on Arch Linux #32

ghost opened this issue Feb 18, 2019 · 4 comments

Comments

@ghost
Copy link

ghost commented Feb 18, 2019

rust-u2f does not work on Arch Linux. I have commented SELinux lines because they don't work. I have used Makefile from linux directory.
When website asks me to press a button, it crashes with the following message:
thread '' panicked at 'called Result::unwrap() on an Err value: Error(Dbus(D-Bus error: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. (org.freedesktop.DBus.Error.NoReply)), State { next_error: None, backtrace: None })', src/libcore/result.rs:1009:5

@danstiner
Copy link
Owner

I'm going to close this since the user has deleted their account. If anyone else tries to get this working on Arch it would be useful to first set RUST_BACKTRACE=1 so we can get a better idea of which line is failing. Given it's a D-Bus error it probably has something to do with how the presence test notification is shown, but I'm not going to dig deeper unless someone is able to help debug (Since I don't have an Arch install handy).

@rhjdvsgsgks
Copy link

i figured out why it happends. DBUS_SESSION_BUS_ADDRESS environment varible is needed to communicate with dbus, but "systemd --user runs outside the user session", so DBUS_SESSION_BUS_ADDRESS not exist in systemd --user environment (you can check that by systemctl --user show-environment). and that caused lot of issue, such as D-Bus error: Failed to connect to socket or D-Bus error: Did not receive a reply

@danstiner
Copy link
Owner

danstiner commented Mar 8, 2022

Interesting, that definitely could be the issue. Thanks for the looking into it. dbus-rs, which I indirectly use via the notify-rust dependency, relies on that env variable: https://github.com/diwic/dbus-rs/blob/949b9c318e08e42df8e278079c47d0a72f376e07/dbus-native-channel/src/address.rs#L14

I was semi-aware of this, so on debian platforms I added a package dependency on dbus-user-session which forces all logins for a user to share a single message bus, and that seems to include systemd user sessions. This is a fairly common package to use, the main downside is you can only have a single graphical session for a user.

I'm not sure if there is an equivalent for Arch, or if you'd want that. In theory the user daemon doesn't care how it's run, it just needs to talk to d-bus to pop notifications on some trusted GUI session and also to read/write it's secrets to your keyring. It also connects to the socket of the u2f system service to create a virtual USB device. That's it, there's no systemd specific behavior and I run the user daemon outside of systemd all the time for testing.

So if you or anyone else has a better solution for Arch feel free to send a PR with code / a README update. Maybe XDG autostart is a better approach, but not sure when I'll have time to look into it myself: https://wiki.archlinux.org/title/autostarting

@danstiner danstiner reopened this Mar 8, 2022
@rhjdvsgsgks
Copy link

i solved it. files provided by dbus-user-session in debain already included in arch package dbus. but you need to set

[Unit]
Wants=dbus.socket
After=dbus.socket

in user daemon unit file to make sure softu2f execute after dbus.socket setup the DBUS_SESSION_BUS_ADDRESS env var. (https://lists.freedesktop.org/archives/systemd-devel/2017-May/038902.html)

and another things breaked that is my desktop mamager will use dbus-launch by default (1, 2). that make DBUS_SESSION_BUS_ADDRESS become some things like unix:abstract=/tmp/dbus-xxx,guid=yyy. it actually started a new dbus, make DBUS_SESSION_BUS_ADDRESS different from it in systemd user session. so the popup will not showed on desktop which useing new DBUS_SESSION_BUS_ADDRESS. after disable that config. DBUS_SESSION_BUS_ADDRESS become same. and popup able to shown

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants