ralf.habacker at freenet.de
Sun Sep 17 17:11:34 PDT 2006
Havoc Pennington schrieb:
> Peter Kümmel wrote:
>> Thanks for the api changes; it's much faster when you change it directly
>> than waiting for the patches of a whining windows guy. ;)
>> I've updated our svn repository, but now we get an regression in the
>> bus test.
>> Have you changed the error handling?
> I haven't, but as I said I made the _unix functions on DBusConnection
> only work on unix. If you run the bus tests with verbose logging then
> I think you'll find it's upset that it can't get the unix user for the
> You'll probably need to add the equivalent of
> connection_set_unix_user_function and connection_get_unix_user for
> Windows, then use those in the bus.
> There may be other issues also, but I'm pretty sure this will be an
> The simple fix: I bet we don't care about the "system bus" on Windows.
> That means we only care about a bus running in the user's session and
> that bus needs to allow the same user to connect while denying all
> other users. Thus, all you have to do is find a way to authenticate
> that a connecting client is owned by the same user as the bus. There's
> no need for the rest of the user-related configuration to work as it
> does on unix. On Windows, user-based security policy matching in the
> config file could just be disallowed for now (ideally, trying to use
> an unsupported option results in an error message).
> If you do it this way, you won't even need the equivalent of
> Come to think of it if you had this working already I probably broke
> it with my dbus-transport.c change. I'll fix that quickly now though
> I'm not sure it will fully fix the bus.
Seems not, we got the following error messages
bin\bus-test.exe: Running SHA1 connection test
NetUserGetInfo() failed: no valid user_info
Using your real home directory for testing, set DBUS_TEST_HOMEDIR to avoid
check_hello_message:837 received message interface "(unset)" member
"(unset)" error name "org.freedesktop.DBus.Error.Fai
led" on 009E1050, expecting not this error
File "F:\daten\windbus\trunk\bus\dispatch.c" line 4054 process 740
should not have been reached: hello message failed
This application has requested the Runtime to terminate it in an unusual
Please contact the application's support team for more information.
DBUS_VERBOSE=1 gives the following error message:
2284: Name :1.0 assigned to 003D9368
2284: LOCK: dbus_connection_get_is_authenticated
2284: UNLOCK: dbus_connection_get_is_authenticated
2284: Appending rule 003D9CE0 with type 0 to policy 009E1CA8
2284: Appending rule 009E5278 with type 1 to policy 009E1CA8
2284: Appending rule 009E1A50 with type 2 to policy 009E1CA8
2284: Failed to create security policy for connection 003D9368
2284: Driver handler returned failure
2284: LOCK: dbus_connection_get_is_connected
2284: UNLOCK: dbus_connection_get_is_connected
2284: Sending error reply org.freedesktop.DBus.Error.Failed "No user ID
known for connection, cannot determine security policy
2284: Sending (no interface) (no member)
org.freedesktop.DBus.Error.Failed from driver
2284: LOCK: dbus_connection_get_data
Any idea ?
> If you do want the security policy stuff as found on UNIX, the first
> question is what should that be like on Windows. I think it should
> probably use the normal Windows authorization / acl mechanism, no?
> This looks potentially relevant (see Authorization) though maybe it
> This is maybe even more useful, see Chapter 6 "UNIX and Windows
> Interoperability" scroll down to the authorization and authentication
> section. Also see Chapter 9 "Win32 Code Conversion" which has a bunch
> of stuff on how to port unix user stuff to Windows:
> It looks to me like an SID structure might be what the Windows
> equivalent of "unix user function" should take?
> The auth protocol currently sends a unix uid over the wire. What are
> you sending for this on Windows? I thought you were using some
> process-specific made-up number for dbus_uid_t? Anyway, my wild guess
> from skimming msdn docs is that this should probably be a username and
> then on successful auth the daemon would do something to "log in" as
> that username and get an sid. I don't know though.
The current implementation takes windows sid's, which are converted to
unix like uid_t type for authentification see _dbus_win_sid_to_uid_t in
2284: _dbus_win_sid_to_uid_t sid
S-1-5-21-117666728-374750965-3721689867-1006 added with uid 49203 to cache
2284: _dbus_getuid() returns 49203
> In the session bus case, normally no uid is sent over the wire because
> the uid is implicit in the socket credentials. So possibly you've just
> been using that codepath on Windows.
> This part of the auth protocol is definitely unix-specific at the
> moment though. I think making parse_uid just barf on Windows might be
> right, because anytime a uid is sent between processes, it does not
> mean anything on Windows.
More information about the dbus