Closed tory-kk closed 1 year ago
This seems to be some weird race condition. I sometimes saw something similar when github actions run the unit tests, but I never found a way to reproduce this locally.
I'll take a look now, maybe your sample will help me finding the cause.
I've just pushed some changes which should fix this issue. At least on my test machine I cannot reproduce this anymore. The test run is even successful when increasing the repeat count to 500.
Tried the latest version and got the following error:
org.freedesktop.dbus.exceptions.AuthenticationException: Cannot authenticate using cookies: Permissions of directory /home/tory/.dbus-keyrings/org_freedesktop_java.lock should be 0600
at org.freedesktop.dbus.connections.SASL.addCookie(SASL.java:155)
at org.freedesktop.dbus.connections.SASL.doResponse(SASL.java:395)
at org.freedesktop.dbus.connections.SASL.auth(SASL.java:650)
at org.freedesktop.dbus.connections.transports.AbstractTransport.authenticate(AbstractTransport.java:197)
at org.freedesktop.dbus.connections.transports.AbstractTransport.internalConnect(AbstractTransport.java:172)
at org.freedesktop.dbus.connections.transports.AbstractTransport.listen(AbstractTransport.java:163)
at org.freedesktop.dbus.bin.EmbeddedDBusDaemon.startListening(EmbeddedDBusDaemon.java:212)
at org.freedesktop.dbus.bin.EmbeddedDBusDaemon.startInForeground(EmbeddedDBusDaemon.java:72)
This directory .dbus-keyrings
had permissions 775 (drwxrwxr-x
). After removing the directory manually and re-running the test, it was re-created with permissions 700 (drwx------
) and all tests became green.
Is there a way to fix backward compatibility?
Hmm.. maybe but that is not what the DBus Spec tells you to do...
Cookies are stored in a user's home directory, in the directory ~/.dbus-keyrings/. This directory must not be readable or writable by other users. If it is, clients and servers must ignore it. The directory contains cookie files named after the cookie context.
That is an excerpt from the DBus Specification. So using the Cookies without validating the permissions of the folder was wrong in all previous versions.
Fixing the permissions without any action by the user is also somehow awkward. Disabling the check is against the Spec.. So which option remains? Adding something in the transport-builder to allow specifying how to behave?
First of all, some warning about the improper directory permissions is needed because seems this cause appears only in debug mode. We are able to fix the directory manually on our machines while other users may not be able to reach their environments after migration to a new version. So such an option in java code would be very useful.
I added some additions to allow configuring that behaviour. The default is not to check permissions. So updating should not break any setup unintentionally
Just checked - everything works. Thanks a lot for such quick responses and solutions :)
Release 4.3.0 was just created, you can expect to find it in maven central tomorrow.
Hello, Recently, we upgraded
dbus-java
from version 2.7.5 to 4.2.1 in our project and after that started facing timeout issues related to establishing a DBus connection in integration tests. These timeouts seem to occur randomly, however, I was able to observe at least once per 100 test repeats with this example: gist.Here are logs from failed test repetition: