bug with 5 code lines
Ralf Habacker
ralf.habacker at freenet.de
Fri Nov 20 10:59:33 PST 2009
Julien Isorce schrieb:
> Hi,
>
> Thx for the reply.
>
> I tried what you suggested:
>
> 2 cases, the first works, the second (the one I want) does not work:
>
> First case:
> ---------------------------------
> I run dbus-daemon --system in command line so the user is Administrator.
> In other cmd, I run dbus-send --print-reply --system
> --dest="org.freedesktop.DBus" /org/freedesktop /DBus/Introspectable
> org.freedesktop.DBus.Introspectable.Introspect
> I got a reply and it's ok.
> I attached the log of the server to this mail:
> dbus-daemon_administrator_classic.log
> ---------------------------------
>
>
> Second case:
> ---------------------------------
I assume in this case you are using DBUS_COOKIE_SHA1 auth
> I run :
> cygrunsrv -I dbus-daemon -i --path
> /cygdrive/c/dbus/dbus-exe/bin/dbus-daemon.exe --chdir
> /cygdrive/c/dbus/dbus-exe --args --system --env DBUS_VERBOSE=1 --env
> DBUS_TEST_HOMEDIR=C:\dbus\dbus-exe
> then: cygrunsrv -S dbus-daemon
> I can then see the dbus-daemon.exe process in task manager and the
> user name is SYSTEM
>
> In other cmd, I run dbus-send --print-reply --system
> --dest="org.freedesktop.DBus" /org/freedesktop /DBus/Introspectable
> org.freedesktop.DBus.Introspectable.Introspect
> The error from the client is: dbus-send.log attached to this mail
the second log contains the following entry:
272: Client authorized as SID 'S-1-5-18' but our SID is 'S-1-5-18',
disconnecting
This message coms from dbus/dbus-transport.c::auth_via_default_rules
(for the complete code see
http://cgit.freedesktop.org/dbus/dbus/tree/dbus/dbus-transport.c)
The default auth rules are [1]:
/* By default, connection is allowed if the client is 1) root or 2)
* has the same UID as us or 3) anonymous is allowed.
*/
if (transport->allow_anonymous ||
_dbus_credentials_get_unix_uid (auth_identity) == 0 ||
_dbus_credentials_same_user (our_identity,
auth_identity))
{
Because none of the condition is true DBUS_COOKIE_SHA1 auth fails (see
the code snippet below)
else
{
if
(_dbus_credentials_include(our_identity,DBUS_CREDENTIAL_WINDOWS_SID))
_dbus_verbose ("Client authorized as SID '%s'"
" but our SID is '%s', disconnecting\n",
_dbus_credentials_get_windows_sid(our_identity),
_dbus_credentials_get_windows_sid(our_identity));
else
_dbus_transport_disconnect (transport);
allow = FALSE;
BTW: The code shows also a bug - for the client the server sid is also
printed. I found this bug in all available dbus implementations and
should be fixed -> patch will follow
If you have the dbus source you may comment out the following line from
[1]
_dbus_credentials_same_user (our_identity,
auth_identity))
then DBUS_COOKIE_SHA1 auth should work.
Because this fix is only a hack it would be interesting to hear from the
dbus design experts how to solve this problem in the official way.
Regards
Ralf
> 2009/11/20 Ralf Habacker <ralf.habacker at freenet.de
> <mailto:ralf.habacker at freenet.de>>
>
> Julien Isorce schrieb:
>
> Hi,
>
> First, thx for the reply.
>
> I follow your advises but I am still not able to use dbus.
> This is my configuration and the result:
>
> - I am launching dbus-daemon.exe --system in a system service
> (using CreateProcess).
>
> this is new land
>
> for quick error reproducing in dbus as system service environment
> a nice solution is to install a service using cygwin's cygrunsrv
> using the following
>
> cygrunsrv -I dbus-daemon -i --path
> <cygwin-style-path-to-dbus-daemon.exe> --chdir
> <cygwin-style-path-to-dbus-install-root> --args --system --env
> DBUS_VERBOSE=1 --env DBUS_TEST_HOMEDIR=<dbus-keyring-home-path>
>
>
> So in task manager I can see that the user name of the
> dbus-daemon process is "SYSTEM" (because of system service)
> - then I open a console and I type: set
> DBUS_SYSTEM_BUS_ADDRESS=tcp:host=localhost,port=12434
> - then I run:
> dbus-send --print-reply --system --dest="org.freedesktop.DBus"
> /org/freedesktop /DBus/Introspectable
> org.freedesktop.DBus.Introspectable.Introspect
>
> -> the result:
>
> <snip>
>
> So I still cannot use dbus with severals users.
> Anyway, the result is at least better than using --session.
> Here it seems that something is not correct (for my needs) in
> the system.conf file.
>
> yes, see below
>
>
> So here is the system.conf file I am using:
> ----------------------------------------------------------------------------------------------------------------------
> <!-- This configuration file controls the systemwide message bus.
> Add a system-local.conf and edit that rather than changing
> this
> file directly. -->
>
> <!-- Note that there are any number of ways you can hose yourself
> security-wise by screwing up this file; in particular, you
> probably don't want to listen on any more addresses, add
> any more
> auth mechanisms, run as a different user, etc. -->
>
> <!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus
> Configuration 1.0//EN"
> "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
> <busconfig>
>
> <!-- Our well-known bus type, do not change this -->
> <type>system</type>
>
> <!-- Run as special user -->
> <user>Administrator</user>
>
> <!-- Fork into daemon mode -->
> <fork/>
>
> <!-- Write a pid file -->
> <pidfile>/dbus-pid</pidfile>
>
> <!-- Only allow socket-credentials-based authentication -->
> <auth>EXTERNAL</auth>
>
> EXTERNAL auth does only work with unix domain sockets and will not
> work on windows (this value is a unix default value)
>
> You may try ANONYMOUS or DBUS_:COOKIE_SHA1, the latter may require
> to set DBUS_TEST_HOMEDIR=<dbus-keyring-home-path>
>
> you shoule enable debug info printing for the server and/or the
> clients by running
>
> set DBUS_VERBOSE=1
>
> Regards
> Ralf
>
>
>
> Ralf
>
>
More information about the dbus
mailing list