Conecting to D-Bus daemon over the network

Bogdan Lotko boguslaw.lotko at chello.at
Fri Feb 18 05:01:15 PST 2011


Well, I've read all this stuff.

The questions are where the e.g. the magic cookie comes from and how the 
server knows it is correct?
What kind of external mechanisms are used by the EXTERNAL authentication 
and how can I control them?
Why when I've specified only one authentication type the daemon checks 
all (see the listing) authentication types?

Finally - is it possible to influence the client authentication?

> We have a small patch for dbus with our private auth mechanism.

Shall this mean, that without this patch the communication is not 
possible?  Then the answer to my original question is "no".
Could you make the patch available to me? I suppose that the client side 
is also concerned (I am using Qt for my real project ).

regards,

Bogdan


On 2/18/2011 13:22, Pavel Strashkin wrote:
> 1. Here you can find information about config file format:
> http://dbus.freedesktop.org/doc/dbus-daemon.1.html
> 2. Here you can find information about how auth works:
> http://dbus.freedesktop.org/doc/dbus-specification.html#auth-examples
>
>> Could you tell me how you've been using the d-bus over the network?
> We have a small patch for dbus with our private auth mechanism.
>
> 2011/2/18 Bogdan Lotko<boguslaw.lotko at chello.at>:
>> Hi,
>>
>> Of course the address was correct, otherwise I couldn't connect. The missing
>> "host=" is only a mail typo.
>>
>> To the main problem:
>> Though I don't understand it, I've tried all three<auth>
>> (ANONYMOUS,EXRERNAL, COOKIE...) possibilities, the results are always
>> similar (no connection).
>>
>> I;ve seen the line, the client probably passes the UID = -1, but what can I
>> do to change it?
>>  From the source code I've understood that the client request contains the
>> authentication credentials.
>> Is there any possibility to tell the client how it shell authenticate?
>> Otherwise I am lost - please remember I am connecting from a remote host,
>> the UIDs don't need to be identical. Does the Authentication has anything to
>> do with rlogin or rsh mechanisms )hosts.equiv, .rhosts or pam access.conf)
>> to do ? I don't think so.
>>
>> Attempting to connect from the same host as the same non-root user also
>> fails. Only the root to root connection on the same host was possible, but
>> this does not solve my problem.
>>
>> Do you know, where I can find the description how the authentication
>> mechanisms are used by D-Bus?
>>
>> Could you tell me how you've been using the d-bus over the network?
>>
>> regards
>>
>> Bogdan
>>
>>
>>
>>
>> On 2/18/2011 12:01, Pavel Strashkin wrote:
>>> 1. Looks like i found the reason. Take a look on it:
>>> 5312: [dbus/dbus-transport.c(676):auth_via_default_rules] Client
>>> authorized as UID 4294967295 but our UID is 1000, disconnecting
>>> As i know ANONYMOUS means that dbus-daemon and client have to be
>>> runned under the same user (at least UIDs have to be equal).
>>> Try to run both under root or another user.
>>>
>>> 2. I want to believe that your connection string is
>>> "tcp:host=192.168.0.8,port=12345", but not
>>> "tcp:192.168.0.8,port=12345"? I don't see "host=" part in your case.
>>>
>>> 3. If all of your services are local then you can use UNIX sockets
>>> instead of TCP/IP, but i believe there is no difference if your
>>> requests rate != 10K/sec :)
>>>
>>> 4. Your test.conf looks good to me, but may be somebody else will add
>>> something.
>>>
>>> 2011/2/18 Bogdan Lotko<boguslaw.lotko at chello.at>:
>>>> Hello Pavel,
>>>>
>>>> Thank you for the rush answer.  I think now is the good  time to explain
>>>> the
>>>> way I'd like to use the D-Bus for my project.
>>>>
>>>> First, this shall be a "private" daemon, I don't intend to connect to the
>>>> session or system daemons, in this way I hope to minimize the security
>>>> risks.
>>>>   /By the way the multiple<listen>    statements in .conf file seem not to
>>>> work
>>>> correctly, as described in dbus-daemon manual (daemon shall listen on all
>>>> addresses), in my case there was impossible to log into the system
>>>> (system
>>>> daemon) or into the session (session daemon)./
>>>>
>>>> The "private" daemon shall work as an ORB for a group of distributed
>>>> programs, with all D-Bus advantages, including the possibility to
>>>> broadcast
>>>> messages to the passive  applications (monitoring displays without
>>>> control
>>>> functionality).
>>>>
>>>> Now to my problems. I've started with the copy of the session.conf file,
>>>> then I've tried to modify it (unfortunately description in dbus-daemon(1)
>>>> is
>>>> not sufficient for me, e.g. it is not clear what different<auth>    options
>>>> mean, the ANONYMOUS authentication is not mentioned at all), you will
>>>> find
>>>> the modified file in the attachment.
>>>>
>>>> In the attachment you will also  find the log of the daemon output in the
>>>> verbose mode.
>>>>
>>>> The client call was:
>>>> conn = dbus_g_connection_open( "tcp:192.168.0.8, port=12345",&error)
>>>>
>>>> I've used the listnames.c example for tests.
>>>>
>>>> bogdan at LotkiSu112:/projects/tests/D-Bus/GLib/listnames>    ldd listnames
>>>>          linux-gate.so.1 =>     (0xffffe000)
>>>>          libdbus-glib-1.so.2 =>    /usr/lib/libdbus-glib-1.so.2 (0xb77f3000)
>>>>          libdbus-1.so.3 =>    /lib/libdbus-1.so.3 (0xb77b0000)
>>>>          libpthread.so.0 =>    /lib/libpthread.so.0 (0xb7796000)
>>>>          librt.so.1 =>    /lib/librt.so.1 (0xb778c000)
>>>>          libgobject-2.0.so.0 =>    /usr/lib/libgobject-2.0.so.0 (0xb7748000)
>>>>          libglib-2.0.so.0 =>    /usr/lib/libglib-2.0.so.0 (0xb7681000)
>>>>          libstdc++.so.6 =>    /usr/lib/libstdc++.so.6 (0xb758d000)
>>>>          libm.so.6 =>    /lib/libm.so.6 (0xb7564000)
>>>>          libgcc_s.so.1 =>    /lib/libgcc_s.so.1 (0xb7544000)
>>>>          libc.so.6 =>    /lib/libc.so.6 (0xb73e4000)
>>>>          /lib/ld-linux.so.2 (0xb7833000)
>>>>          libpcre.so.0 =>    /lib/libpcre.so.0 (0xb73b4000)
>>>>
>>>> Both hosts run SuSE linux 11.2, the used dbus version was dbus-1.4.1,
>>>> compiled with option --enable-verbose-mode (all other settings are
>>>> default).
>>>>
>>>> once more thank you for readiness to help,
>>>>
>>>> with best regards
>>>>
>>>> Bogdan
>>>>
>>>> On 2/18/2011 08:09, Pavel Strashkin wrote:
>>>>
>>>> Hi Bogdan,
>>>>
>>>> Yes, you can use dbus over TCP/IP. I use it in this way within long
>>>> time for local and remote connections. Everything works fine.
>>>> 1. Could you please show the full content of test.conf
>>>> file?file:///H:/files.zip
>>>> 2. When you try to connect  to dbus, what do you see? What the errors?
>>>> What the connection string do you use?
>>>>
>>>> P.S. Simon, do you see that? One more guy want to use dbus over
>>>> TCP/IP! ;) Don't ask why. We really need it and i hope you'll change
>>>> your priorities for unix/tcp as 100%/0% to something like 80%/20% :)
>>>>
>>>> 2011/2/18 Bogdan<b.lotko at chello.at>:
>>>>
>>>> Hello,
>>>>
>>>> I'd like to know if it is possible to connect to the remote D-Bus daemon
>>>> over
>>>> the network. The "tcp:host=hostaddr,port=nr" address form suggest that
>>>> this
>>>> shall be possible, otherwise I don't understand what could it be good
>>>> for.
>>>>
>>>> for tests I've started a dbus-daemon on host A
>>>>   ./dbus-daemon  --config-file=./test.conf
>>>>
>>>> with following statement in the test.conf file:
>>>>
>>>> <listen>"tcp:host=192.168.0.1,port=12345"</listen>
>>>>
>>>> All attempts to connect to this daemon from the another host  failed, the
>>>> problem is the authentication (daemon compiled and started in verbose
>>>> mode).
>>>>
>>>> Please let me know if there is any possibility to connect in such a way
>>>> to
>>>> the
>>>> D-Bus daemon?
>>>> How should the configuration file look like?
>>>> Is there anything to do on the client side?
>>>>
>>>> Unfortunately all these topics are not covered in D-Bus documentation.
>>>>
>>>> Regards,
>>>> B.Lotko
>>>>
>>>>
>>>> _______________________________________________
>>>> dbus mailing list
>>>> dbus at lists.freedesktop.org
>>>> http://lists.freedesktop.org/mailman/listinfo/dbus
>>>>
>>>>
>>>>
>>>>
>>
>



More information about the dbus mailing list